One place for hosting & domains

      Los

      Cómo instalar MongoDB desde los repositorios APT predeterminados de Ubuntu 20.04


      Introducción

      MongoDB es una base de datos de documentos gratuita y de código abierto utilizada comúnmente en las aplicaciones web modernas.

      En este tutorial, instalará MongoDB, administrará su servicio y, de forma opcional, habilitará el acceso remoto.

      Nota: Al momento de la publicación de este artículo, este tutorial instala la versión 3.6 de MongoDB, que es la versión disponible en los repositorios predeterminados de Ubuntu. Sin embargo, generalmente recomendamos instalar la versión más reciente de MongoDB, es decir, la versión 4.4 al momento de la publicación de este artículo. Si desea instalar la versión más reciente de MongoDB, le recomendamos que siga esta guía sobre Cómo instalar MongoDB en Ubuntu 20.04.

      Requisitos previos

      Para seguir este tutorial, necesitará lo siguiente:

      Paso 1: Instalar MongoDB

      En los repositorios oficiales de paquetes de Ubuntu se incluye MongoDB, lo que significa que podemos instalar los paquetes necesarios utilizando apt. Como se mencionó en la introducción, la versión disponible en los repositorios predeterminados no es la más reciente. Para instalar la versión más reciente de Mongo, siga este tutorial.

      Primero, actualice la lista de paquetes para tener la versión más reciente de listados de repositorios:

      A continuación, instale el propio paquete de MongoDB:

      Este comando le solicitará confirmar que quiere instalar el paquete mongodb y sus dependencias. Para hacerlo, presione Y y, luego, ENTER.

      Este comando instala varios paquetes que contienen una versión estable de MongoDB, junto con herramientas de administración útiles para el servidor de MongoDB. El servidor de la base de datos se inicia de forma automática tras la instalación.

      A continuación, comprobaremos que el servidor esté activo y funcione de forma correcta.

      Paso 2: Comprobar el servicio y la base de datos

      El proceso de instalación inició MongoDB de forma automática, pero verificaremos que el servicio se inicie y que la base de datos funcione.

      Primero, compruebe el estado del servicio:

      • sudo systemctl status mongodb

      Verá este resultado:

      Output

      ● mongodb.service - An object/document-oriented database Loaded: loaded (/lib/systemd/system/mongodb.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-10-08 14:23:22 UTC; 49s ago Docs: man:mongod(1) Main PID: 2790 (mongod) Tasks: 23 (limit: 2344) Memory: 42.2M CGroup: /system.slice/mongodb.service └─2790 /usr/bin/mongod --unixSocketPrefix=/run/mongodb --config /etc/mongodb.conf

      Según este resultado, el servidor MongoDB está funcionando.

      Podemos verificar esto en profundidad estableciendo conexión con el servidor de la base de datos y ejecutando el siguiente comando de diagnóstico. Con esto se mostrarán la versión actual de la base de datos, la dirección y el puerto del servidor, y el resultado del comando status:

      • mongo --eval 'db.runCommand({ connectionStatus: 1 })'

      Output

      MongoDB shell version v3.6.8 connecting to: mongodb://127.0.0.1:27017 Implicit session: session { "id" : UUID("e3c1f2a1-a426-4366-b5f8-c8b8e7813135") } MongoDB server version: 3.6.8 { "authInfo" : { "authenticatedUsers" : [ ], "authenticatedUserRoles" : [ ] }, "ok" : 1 }

      Un valor de 1 para el campo ok en la respuesta indica que el servidor funciona correctamente.

      A continuación, veremos la forma de administrar la instancia del servidor.

      Paso 3: Gestionar el servicio de MongoDB

      El proceso de instalación descrito en el Paso 1 configura MongoDB como servicio de systemd, lo que significa que puede administrarlo utilizando comandos systemctl estándares, junto con todos los demás servicios de sistema en Ubuntu.

      Para verificar el estado del servicio, escriba lo siguiente:

      • sudo systemctl status mongodb

      Puede detener el servidor en cualquier momento escribiendo lo siguiente:

      • sudo systemctl stop mongodb

      Para iniciar el servidor cuando esté detenido, escriba lo siguiente:

      • sudo systemctl start mongodb

      También puede reiniciar el servidor con el siguiente comando:

      • sudo systemctl restart mongodb

      Por defecto, MongoDB se configura para iniciarse de forma automática con el servidor. Si desea desactivar el inicio automático, escriba lo siguiente:

      • sudo systemctl disable mongodb

      Puede volver a habilitar el inicio automático en cualquier momento con el siguiente comando:

      • sudo systemctl enable mongodb

      A continuación, ajustaremos la configuración del firewall para nuestra instalación MongoDB.

      Paso 4: Ajustar el firewall (opcional)

      Suponiendo que siguió las instrucciones del tutorial de configuración inicial para servidores para habilitar el firewall en su servidor, no será posible acceder al servidor de MongoDB desde Internet.

      Si tiene intención de usar el servidor de MongoDB solo a nivel local con aplicaciones que se ejecuten en el mismo servidor, este es el ajuste recomendado y seguro. Sin embargo, si desea poder conectarse con su servidor MongoDB desde Internet, deberá permitir las conexiones entrantes añadiendo una regla UFW.

      Para permitir el acceso a MongoDB en su puerto predeterminado 27017 desde cualquier parte, podría ejecutar sudo ufw allow 27017. Sin embargo, permitir el acceso a Internet al servidor de MongoDB en una instalación predeterminada proporciona acceso ilimitado al servidor de la base de datos y a sus datos.

      En la mayoría de los casos, solo se debe acceder a MongoDB desde determinadas ubicaciones de confianza, como otro servidor que aloje una aplicación. Para permitir solo el acceso al puerto predeterminado de MongoDB mediante otro servidor de confianza, puede especificar la dirección IP del servidor remoto en el comando ufw. De esta manera, solo se permitirá que esa máquina se conecte de forma explícita:

      • sudo ufw allow from trusted_server_ip/32 to any port 27017

      Puede verificar el cambio en los ajustes del firewall con ufw:

      Debería ver la habilitación del tráfico hacia el puerto 27017 en el resultado. Tenga en cuenta que si decidió permitir que solo una dirección IP determinada se conecte con el servidor de MongoDB, en el resultado de este comando se enumerará la dirección IP de la ubicación autorizada en lugar de Anywhere.

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 27017 ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 27017 (v6) ALLOW Anywhere (v6)

      Puede encontrar ajustes de firewall más avanzados para restringir el acceso a servicios en Aspectos básicos de UFW: Reglas y comandos comunes de firewall.

      Aunque el puerto esté abierto, MongoDB seguirá escuchando solo en la dirección local 127.0.0.1. Para permitir conexiones remotas, agregue la dirección IP pública de su servidor al archivo mongodb.conf.

      Abra el archivo de configuración de MongoDB en su editor de texto preferido: Este comando de ejemplo utiliza nano:

      • sudo nano /etc/mongodb.conf

      Agregue la dirección IP de su servidor de MongoDB al valor bindIP: Asegúrese de colocar una coma entre la dirección IP existente y la que agregó.

      /etc/mongodb.conf

      ...
      logappend=true
      
      bind_ip = 127.0.0.1,your_server_ip
      #port = 27017
      
      ...
      

      Guarde el archivo y salga del editor. Si utilizó nano para editar el archivo, hágalo pulsando CTRL + X, Y y, luego, ENTER.

      Luego, reinicie el servicio de MongoDB:

      • sudo systemctl restart mongodb

      MongoDB ahora recibirá conexiones remotas, pero cualquiera podrá acceder a él. Siga el tutorial Cómo instalar y proteger MongoDB en Ubuntu 20.04 para agregar un usuario administrativo y ampliar el bloqueo.

      Conclusión

      Puede encontrar tutoriales más detallados sobre cómo configurar y utilizar MongoDB en estos artículos de la comunidad de DigitalOcean. La documentación oficial de MongoDB también es un gran recurso en el que se abordan las posibilidades que ofrece MongoDB.



      Source link

      Cómo procesar los datos de solicitud entrantes en Flask


      Introducción

      Las aplicaciones web requieren con frecuencia el procesamiento de los datos de las solicitudes entrantes de los usuarios. Esta carga útil puede tener la forma de cadenas de consulta, datos de formulario y objetos JSON. Flask, como cualquier otro marco web, le permite acceder a los datos de la solicitud.

      En este tutorial, se creará una aplicación Flask con tres rutas que aceptan cadenas de consulta, datos de formulario u objetos JSON.

      Requisitos previos

      Para completar este tutorial, necesitará lo siguiente:

      • Este proyecto requerirá que Python se instale en un entorno local.
      • Este proyecto usará Pipenv, una herramienta preparada para la producción que pretende traer lo mejor de todos los mundos de empaquetado al mundo de Python. Aprovecha Pipfile, pip, y virtualenv en un solo comando.
      • Se requerirá descargar e instalar una herramienta como Postman para probar los puntos finales de API.

      Este tutorial se verificó con Pipenv v2020.11.15, Python v3.9.0 y Flask v1.1.2.

      Configuración del proyecto

      Para demostrar las diferentes formas de usar solicitudes, deberá crear una aplicación Flask. Aunque la aplicación de ejemplo utiliza una estructura simplificada para las funciones y las rutas de vista, lo que se aprende en este tutorial puede aplicarse a cualquier método de organización de las vistas, como las vistas basadas en clases, los planos o una extensión como Flask-Via.

      Primero, deberá crear un directorio de proyecto. Abra su terminal y ejecute el siguiente comando:

      • mkdir flask_request_example

      Luego, diríjase al nuevo directorio:

      Luego, instale Flask. Abra su terminal y ejecute el siguiente comando:

      El comando pipenv creará un virtualenv para este proyecto, un Pipfile, para instalar flask y un Pipfile.lock.

      Para activar el virtualenv del proyecto, ejecute el siguiente comando:

      Para acceder a los datos entrantes en Flask, tiene que usar el objeto request. El objeto request contiene todos los datos entrantes de la solicitud, que incluye el mimetype, recomendante, dirección IP, datos sin procesar, HTTP y encabezados, entre otras cosas.

      Aunque toda la información que contiene el objeto de solicitud puede ser útil, para los propósitos de este artículo, se centrará en los datos que normalmente son suministrados directamente por la persona que llama al punto final.

      Para obtener acceso al objeto de solicitud en Flask, deberá importarlo desde la biblioteca Flask:

      from flask import request
      

      Luego, podrá usarlo en cualquiera de sus funciones de vista.

      Utilice su editor de código para crear un archivo app.py. Importe Flask y el objeto request. Y también establezca rutas para query-example, form-example, y json-example:

      app.py

      # import main Flask class and request object
      from flask import Flask, request
      
      # create the Flask app
      app = Flask(__name__)
      
      @app.route('/query-example')
      def query_example():
          return 'Query String Example'
      
      @app.route('/form-example')
      def form_example():
          return 'Form Data Example'
      
      @app.route('/json-example')
      def json_example():
          return 'JSON Object Example'
      
      if __name__ == '__main__':
          # run app in debug mode on port 5000
          app.run(debug=True, port=5000)
      

      Luego, abra su terminal e inicie la aplicación con el siguiente comando:

      La aplicación se iniciará en el puerto 5000, por lo que puede ver cada ruta en su navegador con los siguientes enlaces:

      http://127.0.0.1:5000/query-example (or localhost:5000/query-example)
      http://127.0.0.1:5000/form-example (or localhost:5000/form-example)
      http://127.0.0.1:5000/json-example (or localhost:5000/json-example)
      

      El código establece tres rutas y visitar cada una de ellas mostrará los mensajes de "Query String Example", "Form Data Example" y "JSON Object Example", respectivamente.

      Uso de argumentos Query

      Los argumentos de URL que se añaden a una cadena de consulta son una forma común de pasar los datos a una aplicación web. Al navegar por la web, es probable que haya encontrado alguna vez una cadena de consulta.

      Una cadena de consulta se parece a lo siguiente:

      example.com?arg1=value1&arg2=value2
      

      La cadena de consulta comienza después del carácter de signo de interrogación (?) :

      example.com?arg1=value1&arg2=value2
      

      Y tiene pares clave-valor separados por un carácter de “y” comercial (&):

      example.com?arg1=value1&arg2=value2
      

      Para cada par, la clave va seguida por un signo de igualdad (=) y, a continuación, el valor.

      arg1 : value1
      arg2 : value2
      

      Las cadenas de consulta son útiles para pasar datos que no requieren que el usuario realice ninguna acción. Puede generar una cadena de consulta en algún lugar de su aplicación y añadirla a una URL para que cuando un usuario realice una solicitud, los datos se pasen automáticamente para ellos. Una cadena de consulta también puede generarse a través de formularios que tienen GET como método.

      Vamos a añadir una cadena de consulta a la ruta query-example. En este ejemplo hipotético, se proporcionará el nombre de un lenguaje de programación que se mostrará en la pantalla. Cree una clave de "language" y un valor de "Python":

      http://127.0.0.1:5000/query-example?language=Python
      

      Si ejecuta la aplicación y navega a esa URL, verá que sigue mostrando un mensaje de "Query String Example".

      Tendrá que programar la parte que maneja los argumentos de la consulta. Este código leerá la clave de language usando request.args.get('language') o request.args['language'].

      Al invocar request.args.get('language'), la aplicación continuará ejecutándose si la clave de language no existe en la URL. En ese caso, el resultado del método será None.

      Al invocar request.args['language'], la aplicación mostrará un error 400 si la clave de language no existe en la URL.

      Cuando se trata de cadenas de consulta, se recomienda usar request.args.get() para evitar que la aplicación falle.

      Vamos a leer la clave language y mostrarla como resultado.

      Modifique la ruta query-example en app.py con el siguiente código:

      app.py

      @app.route('/query-example')
      def query_example():
          # if key doesn't exist, returns None
          language = request.args.get('language')
      
          return '''<h1>The language value is: {}</h1>'''.format(language)
      

      Luego, ejecute la aplicación y diríjase a la URL:

      http://127.0.0.1:5000/query-example?language=Python
      

      El navegador debe mostrar el siguiente mensaje:

      Output

      The language value is: Python

      El argumento de la URL se asigna a la variable language y luego se devuelve al navegador.

      Para añadir más parámetros de cadena de consulta, puede añadir ampersands y los nuevos pares clave-valor al final de la URL. Cree una clave de "framework" y un valor de "Flask":

      http://127.0.0.1:5000/query-example?language=Python&framework=Flask
      

      Y si desea más, continúe añadiendo ampersands y pares clave-valor. Cree una clave de "website" y un valor de "DigitalOcean":

      http://127.0.0.1:5000/query-example?language=Python&framework=Flask&website=DigitalOcean
      

      Para obtener acceso a esos valores, seguirá usando request.args.get() o request.args[]. Vamos a usar ambos para demostrar lo que sucede cuando falta una clave. Modifique la ruta query_example para asignar el valor de los resultados a variables y luego mostrarlos:

      @app.route('/query-example')
      def query_example():
          # if key doesn't exist, returns None
          language = request.args.get('language')
      
          # if key doesn't exist, returns a 400, bad request error
          framework = request.args['framework']
      
          # if key doesn't exist, returns None
          website = request.args.get('website')
      
          return '''
                    <h1>The language value is: {}</h1>
                    <h1>The framework value is: {}</h1>
                    <h1>The website value is: {}'''.format(language, framework, website)
      

      Luego, ejecute la aplicación y diríjase a la URL:

      http://127.0.0.1:5000/query-example?language=Python&framework=Flask&website=DigitalOcean
      

      El navegador debe mostrar el siguiente mensaje:

      Output

      The language value is: Python The framework value is: Flask The website value is: DigitalOcean

      Elimine la clave de language de la URL:

      http://127.0.0.1:5000/query-example?framework=Flask&website=DigitalOcean
      

      El navegador debe mostrar el siguiente mensaje con None cuando no se proporciona un valor para language:

      Output

      The language value is: None The framework value is: Flask The website value is: DigitalOcean

      Elimine la clave de framework de la URL:

      http://127.0.0.1:5000/query-example?language=Python&website=DigitalOcean
      

      El navegador debería encontrar un error porque está esperando un valor para framework:

      Output

      werkzeug.exceptions.BadRequestKeyError werkzeug.exceptions.BadRequestKeyError: 400 Bad Request: The browser (or proxy) sent a request that this server could not understand. KeyError: 'framework'

      Ahora, ya comprende cómo se manejan las cadenas de consulta. Continuemos con el siguiente tipo de datos entrantes.

      Uso de datos de formulario

      Los datos de formulario provienen de un formulario que ha sido enviado como solicitud POST a una ruta. Por lo tanto, en lugar de ver los datos en la URL (excepto en los casos en que el formulario se envía con una solicitud GET), los datos del formulario pasarán a la aplicación entre bastidores. Aunque no se pueden ver fácilmente los datos del formulario que se pasan, su aplicación puede leerlos.

      Para demostrarlo, modifique la ruta de form-example en app.py para aceptar las solicitudes GET y POST, y devolver un formulario:

      app.py

      # allow both GET and POST requests
      @app.route('/form-example', methods=['GET', 'POST'])
      def form_example():
          return '''
                    <form method="POST">
                        <div><label>Language: <input type="text" name="language"></label></div>
                        <div><label>Framework: <input type="text" name="framework"></label></div>
                        <input type="submit" value="Submit">
                    </form>'''
      

      Luego, ejecute la aplicación y diríjase a la URL:

      http://127.0.0.1:5000/form-example
      

      El navegador debe mostrar un formulario con dos campos de entrada, uno para language y otro para framework, así como para un botón de envío.

      Lo más importante que hay que saber sobre este formulario es que realiza una solicitud POST a la misma ruta que generó el formulario. Las claves que se leerán en la aplicación provienen de los atributos de nombre de las entradas de nuestro formulario. En este caso, language y framework son los nombres de las entradas, por lo que tendrá acceso a ellos en la aplicación.

      Dentro de la función de vista, deberá verificar si el método de solicitud es GET o POST. Si es una solicitud GET, puede mostrar el formulario. De lo contrario, si se trata de una solicitud POST, entonces querrá procesar los datos entrantes.

      Modifique la ruta de form-example en app.py con el siguiente código:

      app.py

      # allow both GET and POST requests
      @app.route('/form-example', methods=['GET', 'POST'])
      def form_example():
          # handle the POST request
          if request.method == 'POST':
              language = request.form.get('language')
              framework = request.form.get('framework')
              return '''
                        <h1>The language value is: {}</h1>
                        <h1>The framework value is: {}</h1>'''.format(language, framework)
      
          # otherwise handle the GET request
          return '''
                 <form method="POST">
                     <div><label>Language: <input type="text" name="language"></label></div>
                     <div><label>Framework: <input type="text" name="framework"></label></div>
                     <input type="submit" value="Submit">
                 </form>'''
      

      Luego, ejecute la aplicación y diríjase a la URL:

      http://127.0.0.1:5000/form-example
      

      Complete el campo de language con el valor de Python y el campo de framework con el valor de Flask. Luego, presione Submit (Enviar).

      El navegador debe mostrar el siguiente mensaje:

      Output

      The language value is: Python The framework value is: Flask

      Ahora, entiende cómo manejar los datos del formulario. Continuaremos con el siguiente tipo de datos entrantes.

      Uso de datos JSON

      Los datos JSON generalmente se construye a través de un proceso que invoca la ruta.

      Un ejemplo de objeto JSON tiene el siguiente aspecto:

      {
        "language": "Python",
        "framework": "Flask",
        "website": "Scotch",
        "version_info": {
          "python": "3.9.0",
          "flask": "1.1.2"
        },
        "examples": ["query", "form", "json"],
        "boolean_test": true
      }
      

      Esta estructura puede permitir que se pasen datos mucho más complicados en lugar de las cadenas de consulta y los datos del formulario. En el ejemplo, se ve los objetos JSON anidados y una matriz de elementos. Flask puede gestionar este formato de datos.

      Modifique la ruta de form-example en app.py para aceptar las solicitudes POST e ignore otras solicitudes como GET:

      app.py

      @app.route('/json-example', methods=['POST'])
      def json_example():
          return 'JSON Object Example'
      

      A diferencia del navegador web que se utiliza para las cadenas de consulta y los datos de formulario, para los fines de este artículo, para enviar un objeto JSON, se utilizará Postman para enviar solicitudes personalizadas a las URL.

      Nota: Si necesita ayuda para navegar por la interfaz de Postman para las solicitudes, consulte la documentación oficial.

      En Postman, añada la URL y cambie el tipo a POST. En la pestaña de cuerpo, cambie a raw y seleccione JSON en el menú desplegable.

      Estos ajustes son necesarios para que Postman pueda enviar datos JSON correctamente, y para que su aplicación Flask comprenda que está recibiendo JSON:

      POST http://127.0.0.1:5000/json-example
      Body
      raw JSON
      

      Luego, copie el ejemplo JSON anterior en la entrada de texto.

      Envíe la solicitud y debería obtener "JSON Object Example" como respuesta. Eso es bastante decepcionante, pero es de esperar porque el código para gestionar la respuesta de los datos JSON aún no se ha escrito.

      Para leer los datos, debe entender cómo Flask traduce los datos JSON en las estructuras de datos de Python:

      • Cualquier cosa que sea un objeto se convierte en una dictadura de Python. {"key" : "value"} en JSON corresponde a somedict['key'], que devuelve un valor en Python.
      • Una matriz en JSON se convierte en una lista en Python. Dado que la sintaxis es la misma, aquí hay un ejemplo de una lista: [1,2,3,4,5].
      • Los valores dentro de las comillas en el objeto JSON se convierten en cadenas en Python.
      • Los booleanos true y false se convierten en True y False en Python.
      • Por último, los números sin comillas se convierten en números en Python.

      Ahora vamos a trabajar en el código para leer los datos JSON entrantes.

      Primero, vamos a asignar todo desde el objeto JSON a una variable usando request.get_json().

      request.get_json() convierte el objeto JSON en datos de Python. Asignemos los datos de la solicitud entrante a las variables y devolvámoslos haciendo los siguientes cambios en la ruta json-example:

      app.py

      # GET requests will be blocked
      @app.route('/json-example', methods=['POST'])
      def json_example():
          request_data = request.get_json()
      
          language = request_data['language']
          framework = request_data['framework']
      
          # two keys are needed because of the nested object
          python_version = request_data['version_info']['python']
      
          # an index is needed because of the array
          example = request_data['examples'][0]
      
          boolean_test = request_data['boolean_test']
      
          return '''
                 The language value is: {}
                 The framework value is: {}
                 The Python version is: {}
                 The item at index 0 in the example list is: {}
                 The boolean value is: {}'''.format(language, framework, python_version, example, boolean_test)
      

      Tenga en cuenta cómo se accede a los elementos que no están en el nivel superior. Se utiliza ['version']['python'] porque se está entrando en un objeto anidado. Y ['examples'][0] se utiliza para acceder al índice 0 en la matriz de ejemplos.

      Si el objeto JSON enviado con la solicitud no tiene una clave a la que se accede en su función de vista, entonces la solicitud fallará. Si no quiere que la solicitud falle cuando no existe una clave, tendrá que verificar si la clave existe antes de intentar ingresarla.

      app.py

      # GET requests will be blocked
      @app.route('/json-example', methods=['POST'])
      def json_example():
          request_data = request.get_json()
      
          language = None
          framework = None
          python_version = None
          example = None
          boolean_test = None
      
          if request_data:
              if 'language' in request_data:
                  language = request_data['language']
      
              if 'framework' in request_data:
                  framework = request_data['framework']
      
              if 'version_info' in request_data:
                  if 'python' in request_data['version_info']:
                      python_version = request_data['version_info']['python']
      
              if 'examples' in request_data:
                  if (type(request_data['examples']) == list) and (len(request_data['examples']) > 0):
                      example = request_data['examples'][0]
      
              if 'boolean_test' in request_data:
                  boolean_test = request_data['boolean_test']
      
          return '''
                 The language value is: {}
                 The framework value is: {}
                 The Python version is: {}
                 The item at index 0 in the example list is: {}
                 The boolean value is: {}'''.format(language, framework, python_version, example, boolean_test)
      

      Ejecute la aplicación y envíe la solicitud JSON de ejemplo usando Postman. En la respuesta, obtendrá el siguiente resultado:

      Output

      The language value is: Python The framework value is: Flask The Python version is: 3.9 The item at index 0 in the example list is: query The boolean value is: false

      Ahora comprende cómo se manejan los objetos JSON.

      Conclusión

      En este artículo, se creó una aplicación Flask con tres rutas que aceptan cadenas de consulta, datos de formulario u objetos JSON.

      Además, recuerde que todos los enfoques tuvieron que abordar la consideración recurrente de fallar con gracia cuando falta una clave.

      Advertencia: Un tema que no se cubrió en este artículo fue cómo desinfectar la entrada de los usuarios. La sanitización de la entrada de lo usuario garantizaría que los datos leídos por la aplicación no causen un fallo inesperado o que se salten las medidas de seguridad.

      Si desea obtener más información sobre Flask, consulte nuestra página del tema Flask para consultar ejercicios y proyectos de programación.



      Source link

      Cómo usar Journalctl para ver y manipular los registros de Systemd


      Introducción

      Algunas de las ventajas más convincentes de systemd son las que se relacionan con el proceso y registro del sistema. Al usar otros sistemas, los registros suelen estar dispersos por todo el sistema, son manejados por diferentes demonios y herramientas, y puede ser bastante difícil de interpretar cuando abarcan varias aplicaciones. Systemd intenta resolver estos problemas al proporcionar una solución de administración centralizada para registrar todos los procesos del kernel y del usuario. El sistema que recopila y administra estos registros se conoce como diario.

      El diario se implementa con el demonio journald, que gestiona todos los mensajes producidos por el kernel, initrd, servicios, etc. En esta guía, veremos cómo usar la utilidad journalctl, que puede usarse para acceder y manipular los datos que se encuentran dentro del diario.

      Idea general

      Uno de los impulsos detrás del diario systemd es centralizar la administración de los registros, independientemente de dónde se originen los mensajes. Dado que el proceso systemd gestiona gran parte del proceso de arranque y administración de servicios, tiene sentido estandarizar la forma en que se recopila y acceden a estos registros. El demonio journald recopila datos de todas las fuentes disponibles y los almacena en un formato binario para una manipulación fácil y dinámica.

      Eso nos proporciona varias ventajas significativas. Al interactuar con los datos usando una sola utilidad, los administradores pueden mostrar datos de registro de forma dinámica según sus necesidades. Esto puede ser tan simple como ver los datos del arranque de hace tres arranques o combinar las entradas de registro de forma secuencial de dos servicios relacionados para depurar un problema de comunicación.

      Almacenar los datos de registro en formato binario también significa que los datos pueden mostrarse en formatos de salida arbitrarios dependiendo de lo que se necesite en el momento. Por ejemplo, para la gestión de los registros diarios puede que esté acostumbrado a ver los registros en el formato estándar de syslog, pero si decide graficar las interrupciones del servicio más adelante, puede mostrar cada entrada como un objeto JSON para que sea consumible en su servicio gráfico. Dado que los datos no se escriben en el disco en texto plano, no es necesario convertirlos cuando se necesita un distinto formato bajo demanda.

      El diario systemd puede usarse con una implementación de syslog existente o puede sustituir la funcionalidad syslog, según sus necesidades. Aunque el diario systemd cubrirá la mayoría de las necesidades de registro del administrador, también puede complementar los mecanismos de registro existentes. Por ejemplo, es posible que tenga un servidor syslog centralizado que utilice para compilar datos de varios servidores, pero también es posible que quiera interconectar los registros de varios servicios en un solo sistema con el diario systemd. Puede hacer ambas cosas combinando estas tecnologías.

      Configurar la hora del sistema

      Una de las ventajas de usar un diario binario para el registro es la posibilidad de ver los registros en hora UTC o local libremente. systemd mostrará los resultados en hora local de manera predeterminada.

      Debido a esto, antes de comenzar con el diario, nos aseguraremos de que la zona horaria esté configurada correctamente. El paquete de systemd realmente viene con una herramienta llamada timedatectl que puede ayudar con esto.

      Primero, consulte qué zonas horarias están disponibles con la opción list-timezones:

      timedatectl list-timezones
      

      Esto mostrará la lista de zonas horarias disponibles en su sistema. Cuando encuentre la que coincida con la ubicación de su servidor, puede configurarla usando la opción set-timezone:

      sudo timedatectl set-timezone zone
      

      Para asegurarse de que su máquina esté usando la hora correcta actual, utilice el comando timedatectl solo o con la opción status. En la pantalla, se mostrará lo mismo:

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      La primera línea debe mostrar la hora correcta.

      Visualización básica de registros

      Para ver los registros que el demonio journald ha recopila el comando journalctl.

      Cuando se utilice solo, cada entrada de diario que se encuentre en el sistema se mostrará dentro de un localizador (por lo general, less) para que pueda navegar en él Las entradas más antiguas estarán arriba:

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      Es probable que tenga que desplazarse por páginas y páginas de datos, que pueden ser decenas o cientos de miles de líneas si systemd ha estado en su sistema por mucho tiempo. Esto demuestra la cantidad de datos disponibles en la base de datos del diario.

      El formato será familiar para aquellos que se utilizan para el registro syslog estándar. Sin embargo, esto realmente recopila datos de más fuentes de las que las implementaciones syslog tradicionales son capaces de recopilar. Incluye registros del proceso de arranque inicial, el kernel, el initrd, el error de estándar de la aplicación y la salida. Todos ellos están disponibles en el diario.

      Es posible que observe que todas las marcas de tiempo que se muestran son de hora local. Esto está disponible para cada entrada de registro ahora que tenemos nuestro tiempo local correctamente configurado en el sistema. Todos los registros se muestran usando esta nueva información.

      Si desea mostrar las marcas de tiempo en hora UTC, puede usar el indicador --utc:

      journalctl --utc
      

      Filtrado del diario por hora

      A pesar de que tener acceso a una colección tan grande de datos es definitivamente útil, es difícil o imposible inspeccionar y procesar mentalmente tal gran cantidad de datos. Debido a esto, una de las características más importantes de journalctl son sus opciones de filtrado.

      Mostrar los registros del arranque actual

      La más básica de estas que puede usar diariamente, es el indicador -b. Este indicador mostrará todas las entradas del diario que se recopilaron desde el reinicio más reciente.

      journalctl -b
      

      Esto le ayudará a identificar y administrar la información que sea pertinente para su entorno actual.

      En los casos en que no se usa esta función y se muestran más de un día de arranques, verá que journalctl insertó una línea parecida a la siguiente cada vez que el sistema se cae:

      . . .
      
      -- Reboot --
      
      . . .
      

      Lo puede usar para separar la información de manera lógica en sesiones de arranque.

      Arranques anteriores

      Aunque por lo general querrá mostrar la información del arranque actual, hay ocasiones en que los arranques anteriores también son útiles. El diario puede guardar la información de varios arranques anteriores, por lo que journalctl puede usarse para mostrar la información más fácilmente.

      Algunas distribuciones permiten guardar la información de los arranques anteriores de manera predeterminada, mientras que otras deshabilitan esta función. Para habilitar la información de arranque persistente, puede crear el directorio para almacenar el diario escribiendo lo siguiente:

      • sudo mkdir -p /var/log/journal

      O puede editar el archivo de configuración del diario:

      • sudo nano /etc/systemd/journald.conf

      En la sección [Journal], establezca la opción Storage= en “persistent” (persistente) para habilitar el registro persistente:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Cuando la opción de guardar los arranques anteriores está habilitada en su servidor, journalctl proporciona algunos comandos para ayudarlo a trabajar con los arranques como unidad de división. Para ver los arranques que journald conoce, utilice la opción --list-boots con journalctl:

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Esto mostrará una línea para cada arranque. La primera columna es la compensación del arranque que puede usarse para hacer referencia fácilmente al arranque con journalctl. Si necesita una referencia absoluta, el ID del arranque está en la segunda columna. Puede saber la hora a la que se refiere la sesión de arranque con las dos especificaciones de hora que aparecen al final.

      Para mostrar la información de estos arranques, puede usar la información de la primera o la segunda columna.

      Por ejemplo, para ver el diario del arranque anterior, utilice el puntero relativo -1 con el indicador -b:

      journalctl -b -1
      

      También puede usar el ID de arranque invocar los datos de un arranque:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Ventanas de tiempo

      Aunque ver las entradas de registro por arranque es increíblemente útil, en ocasiones es posible que quiera solicitar ventanas de tiempo que no se alinean bien con el arranque del sistema. Este puede ser el caso especialmente cuando se trata de servidores de larga duración con un tiempo de actividad significativo.

      Puede filtrar por límites de tiempo arbitrarios usando las opciones --since y --until, que restringen las entradas mostradas a aquellas posteriores o anteriores al tiempo indicado, respectivamente.

      Los valores de tiempo pueden venir en varios formatos. Para los valores absolutos de tiempo, debe usar el siguiente formato:

      YYYY-MM-DD HH:MM:SS
      

      Por ejemplo, podemos ver todas las entradas desde el 10 de enero de 2015 a las 5:15 p. m. escribiendo:

      journalctl --since "2015-01-10 17:15:00"
      

      Si se omiten los componentes del formato anterior, se aplicarán algunos valores predeterminados. Por ejemplo, si se omite la fecha, se asumirá la fecha actual. Si falta el componente que hace referencia a la hora, se sustituirá por “00:00:00” (medianoche). El campo de los segundos también se puede omitir para que aparezca “00” de manera predeterminada:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      El diario también comprende algunos valores relativos y los accesos directos con nombre. Por ejemplo, puede usar las palabras “yesterday”, “today”, “tomorrow”, o “now”. Puede hacer referencia a tiempos relativos anteponiendo “-” o “+” a un valor numérico o utilizando palabras como “ago” en la construcción de las instrucciones.

      Para obtener los datos del día de ayer, puede escribir lo siguiente:

      journalctl --since yesterday
      

      Si recibió informes de una interrupción del servicio que comenzó a las 9:00 a.m. y continuó hasta hace una hora, puede escribir lo siguiente:

      journalctl --since 09:00 --until "1 hour ago"
      

      Como puede ver, es relativamente fácil definir ventanas de tiempo flexibles para filtrar las entradas que desea ver.

      Filtrado por interés de mensaje

      En la sección anterior hemos aprendido algunas formas de filtrar los datos del diario utilizando restricciones de tiempo. En esta sección, veremos cómo filtrar según el servicio o componente que le interese. El diario systemd proporciona varias formas de hacer esto.

      Por unidad

      Probablemente la forma más útil de filtrar es por la unidad que le interesa. Podemos usar la opción -u para filtrar de esta manera.

      Por ejemplo, para ver todos los registros de una unidad de Nginx en nuestro sistema, podemos escribir lo siguiente:

      journalctl -u nginx.service
      

      Por lo general, también querrá filtrar por tiempo para mostrar las líneas que le interesa. Por ejemplo, para comprobar cómo se está ejecutando el servicio hoy, puede escribir lo siguiente:

      journalctl -u nginx.service --since today
      

      Este tipo de enfoque resulta extremadamente útil cuando se aprovecha la capacidad del diario para intercalar registros de varias unidades. Por ejemplo, si su proceso de Nginx está conectado a una unidad PHP-FPM para procesar contenido dinámico, puede combinar las entradas de ambos en orden cronológico especificando ambas unidades:

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Eso puede hacer que sea mucho más fácil detectar las interacciones entre diferentes programas y sistemas de depuración en vez de procesos individuales.

      Por proceso, usuario o ID de grupo

      Algunos servicios generan varios procesos secundarios para realizar el trabajo. Si ha localizado el PID exacto del proceso que le interesa, también se puede hacer un filtrado basándonos en eso.

      Para hacer esto, podemos filtrar especificando el campo _PID. Por ejemplo, si el PID que nos interesa es 8088, podemos escribir lo siguiente:

      journalctl _PID=8088
      

      En otras ocasiones, es posible que quiera mostrar todas las entradas registradas de un usuario o de un grupo específico. Esto puede hacerse con los filtros _UID o _GID. Por ejemplo, si su servidor web se ejecuta bajo el usuario www-data, puede encontrar el ID de usuario escribiendo lo siguiente:

      id -u www-data
      
      33
      

      Luego, puede usar el ID que salió en la búsqueda para filtrar los resultados del diario:

      journalctl _UID=33 --since today
      

      El diario systemd tiene muchos campos que pueden usarse para filtrar. Algunos de estos son pasados desde el proceso que se está registrando y otros son aplicados por journald usando la información que recopila del sistema en el momento del registro.

      El símbolo inicial de guion bajo indica que el campo _PID es de este último tipo. El diario registra e indexa automáticamente el PID del proceso que está registrando para filtrarlo después. Puede obtener información sobre todos los campos disponibles del diario escribiendo lo siguiente:

      man systemd.journal-fields
      

      En esta guía, veremos algunas de estas opciones. Por ahora, sin embargo, vamos a repasar una opción más útil que tiene que ver con el filtrado mediante estos campos. La opción -F puede usarse para mostrar todos los valores disponibles para un determinado campo del diario.

      Por ejemplo, para ver qué ID de grupo tiene entradas el diario systemd, puede escribir lo siguiente:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Esto mostrará todos los valores que el diario almacenó para el campo del ID de grupo. Esto puede ayudarlo a crear sus filtros.

      Por ruta de componente

      También podemos filtrar proporcionando una ubicación de ruta.

      Si la ruta conduce a un ejecutable, journalctl mostrará todas las entradas que implican el ejecutable en cuestión. Por ejemplo, para encontrar aquellas entradas que implican el ejecutable bash, puede escribir lo siguiente:

      journalctl /usr/bin/bash
      

      Por lo general, si una unidad está disponible para el ejecutable, ese método es más limpio y proporciona mejor información (entradas de procesos secundarios asociados, etc.). A veces, sin embargo, eso no es posible.

      Mostrar mensajes de kernel

      Los mensajes de kernel, que suelen encontrarse en el resultado de dmesg, también se pueden recuperar del diario.

      Para mostrar solo estos mensajes, podemos añadir los indicadores -k o --dmesg a nuestro comando:

      journalctl -k
      

      De manera predeterminada, esto mostrará los mensajes del kernel del arranque actual. Puede especificar un arranque alternativo usando los indicadores normales de selección de arranque que se mostraron anteriormente. Por ejemplo, para obtener los mensajes de hace cinco arranques, puede escribir lo siguiente:

      journalctl -k -b -5
      

      Por prioridad

      Un filtro que suele interesar a los administradores de sistemas es el de prioridad de mensaje. Aunque a menudo es útil registrar información a un nivel muy verboso, cuando realmente se asimila la información disponible, los registros de baja prioridad pueden distraer y confundir.

      Puede usar journalctl para mostrar solo mensajes de una prioridad especifica o superior usando la opción -p. Esto le permite filtrar mensajes de menor prioridad.

      Por ejemplo, para mostrar solo las entradas registradas en el nivel de error o superior, puede escribir lo siguiente:

      journalctl -p err -b
      

      Esto le mostrará todos los mensajes marcados como error, crítico, alerta o emergencia. El diario implementa los niveles de mensaje syslog estándar. Puede usar el nombre de prioridad o su valor numérico correspondiente. En orden de mayor a menor prioridad, estos son:

      • 0: emergencia
      • 1: alerta
      • 2: crítico
      • 3: error
      • 4: advertencia
      • 5: aviso
      • 6: información
      • 7: depuración

      Los números o nombres anteriores pueden usarse indistintamente con la opción -p. Al seleccionar una prioridad, se mostrarán los mensajes marcados en el nivel especificado y aquellos que se encuentran por encima.

      Modificar la pantalla del diario

      Anteriormente, hemos demostrado la selección de entradas mediante el filtrado. Sin embargo, hay otras formas de modificar el resultado. Podemos ajustar la pantalla journalctl para que se adapte a varias necesidades.

      Truncar o ampliar el resultado

      Podemos ajustar la forma en que journalctl muestra datos indicándole que reduzca o amplíe el resultado.

      Por defecto, journalctl mostrará toda la entrada en el localizador, permitiendo que las entradas se desplacen a la derecha de la pantalla. Se puede acceder a esta información presionando la tecla de flecha derecha.

      Si prefiere truncar el resultado, insertar un elipses donde se eliminó la información, puede usar la opción --no-full:

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      También puede hacer lo opuesto e indicarle a journalctl que muestre toda la información, independientemente de si incluye caracteres no imprimibles. Podemos hacerlo con el indicador -a:

      journalctl -a
      

      Resultado a la salida estándar

      Por defecto, journalctl muestra el resultado en un localizador para un uso más sencillo. Sin embargo, si está planeando procesar los datos con herramientas de manipulación de texto, es probable que quiera poder mostrar un resultado estándar.

      Puede hacer esto con la opción --no-pager:

      journalctl --no-pager
      

      Se puede canalizar inmediatamente a una utilidad de procesamiento o redireccionar a un archivo en el disco, dependiendo de sus necesidades.

      Formatos de resultado

      Si está procesando las entradas del diario, como se mencionó anteriormente, es probable que le resulte más fácil analizar los datos si están en un formato más fácil de usar. Afortunadamente, el diario puede mostrarse en varios formatos según sea necesario. Puede hacerlo usando la opción -o con un especificador de formato.

      Por ejemplo, puede mostrar las entradas del diario en JSON escribiendo lo siguiente:

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Eso es útil para el análisis sintáctico con utilidades. Puede usar el formato json-pretty para obtener un mejor manejo de la estructura de datos antes de transmitirla al consumidor JSON:

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Se pueden usar los siguientes formatos para la visualización:

      • cat: Muestra solo el campo de mensaje.
      • export: Formato binario adecuado para transferir o hacer copias de seguridad.
      • json: JSON estándar con una entrada por línea.
      • json-pretty: JSON formateado para una mejor legibilidad humana
      • json-sse: Resultado formateado JSON envuelto para hacer que el evento enviado por servidor sea compatible
      • short: El resultado de estilo syslog predeterminado
      • short-iso: El formato predeterminado aumentado para mostrar las marcas de tiempo del reloj de pared ISO 8601.
      • short-monotonic: El formato predeterminado con marcas de tiempo monotónicas.
      • short-precise: El formato predeterminado con precisión de microsegundos.
      • verbose: Muestra todos los campos del diario disponibles para la entrada, incluidos los que suelen estar ocultos internamente.

      Estas opciones le permiten mostrar las entradas del diario en el formato que mejor se adapte a sus necesidades actuales.

      Supervisión activa de procesos

      El comando journalctl imita la cantidad de administradores que utilizan tail para supervisar la actividad activa o reciente. Esta funcionalidad está incorporada en journalctl, lo que le permite acceder a estas funciones sin necesidad de recurrir a otra herramienta.

      Cómo mostrar los registros recientes

      Para mostrar una cantidad determinada de registros, puede usar la opción -n, que funciona exactamente igual que tail -n.

      Por defecto, se mostrarán las 10 entradas más recientes:

      journalctl -n
      

      Puede especificar el número de entradas que desea ver agregando un número después de -n:

      journalctl -n 20
      

      Cómo hacer un seguimiento de los registros

      Para seguir activamente los registros a medida que se escriben, puede usar el indicador -f. Una vez más, esto funciona de la manera prevista si tiene experiencia usando tail -f:

      journalctl -f
      

      Mantenimiento del diario

      Es posible que se esté preguntando sobre el costo de almacenar todos los datos que hemos visto hasta ahora. Además, puede que le interese limpiar algunos registros antiguos y liberar espacio.

      Cómo encontrar el uso actual de disco

      Puede averiguar la cantidad de espacio que el diario está ocupando actualmente en el disco usando la opción el indicador --disk-usage:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Cómo eliminar registros antiguos

      Si desea reducir su diario, puede hacerlo de dos distintas formas (disponibles en la versión 218 y posterior de systemd).

      Si usa la opción --vacuum-size, puede reducir su diario indicando un tamaño. Esto eliminará las entradas antiguas hasta que el espacio total del diario ocupado en el disco sea del tamaño solicitado:

      sudo journalctl --vacuum-size=1G
      

      Otra forma de reducir el diario es proporcionar un tiempo límite con la opción --vacuum-time. Cualquier entrada que sobrepase ese límite de tiempo será eliminada. Esto le permite mantener las entradas que se han creado después de un tiempo específico.

      Por ejemplo, para guardar las entradas del último año, puede escribir lo siguiente:

      sudo journalctl --vacuum-time=1years
      

      Cómo limitar la expansión del diario

      Puede configurar su servidor para que ponga límites sobre cantidad de espacio que puede ocupar el diario. Puede hacer esto editando el archivo /etc/systemd/journald.conf

      Puede usar los siguientes elementos para limitar la expansión del diario:

      • SystemMaxUse=: especifica el espacio máximo de disco que puede usar el diario en el almacenamiento persistente.
      • SystemKeepFree=: especifica la cantidad de espacio que el diario debe dejar libre al añadir entradas del diario al almacenamiento persistente.
      • SystemMaxFileSize=: controla el tamaño que pueden alcanzar los archivos individuales del diario en el almacenamiento persistente antes de rotar.
      • RuntimeMaxUse=: especifica el espacio máximo de disco que puede usarse en el almacenamiento volátil (dentro del sistema de archivos /run).
      • RuntimeKeepFree=: especifica la cantidad de espacio que debe reservarse para otros usos al escribir datos en el almacenamiento volátil (dentro del sistema de archivos /run).
      • RuntimeMaxFileSize=: especifica la cantidad de espacio que puede ocupar un archivo de diario individual en el almacenamiento volátil (dentro del sistema de archivos /run) antes de rotar.

      Al establecer estos valores, puede controlar la forma en que journald utiliza y preserva el espacio en su servidor. Tenga en cuenta que SystemMaxFileSize y RuntimeMaxFileSize orientarán los archivos para llegar a los límites indicados. Es importante recordar esto al interpretar el recuento de archivos después de una operación vaciado.

      Conclusión

      Como puede ver, el diario systemd es increíblemente útil para recopilar y administrar los datos de su sistema y aplicación. Su flexibilidad proviene, en mayor parte, de los amplios metadatos registrados automáticamente y del carácter centralizado del registro. El comando journalctl hace que sea fácil aprovechar las funciones avanzadas del diario, realizar amplios análisis y depurar de forma relacional los diferentes componentes de la aplicación.



      Source link