Original: https://prometheus.io/docs/prometheus/latest/storage/
Directorio de artículos
Prometheus incluye una base de datos de series de tiempo de disco local, pero también puede optar por integrarse con sistemas de almacenamiento remoto.
Almacenamiento local
La base de datos de series de tiempo local de Prometheus almacena datos de series de tiempo en el disco en un formato personalizado.
Diseño en disco
La muestra ingerida se divide en dos horas. Cada período de tiempo de dos horas contiene un directorio que contiene uno o más archivos de bloque que contienen todas las muestras de series de tiempo de la ventana de tiempo, así como archivos de metadatos y archivos de índice (el archivo de índice combina el nombre de la métrica y la serie de tiempo de las etiquetas indexadas en bloquear archivos)). Al eliminar una serie a través de la API, el registro de eliminación se almacena en un archivo de desecho separado (en lugar de eliminar inmediatamente los datos del archivo de bloque).
El bloque de la muestra entrante actual se guarda en la memoria y no se ha reservado por completo. Evita bloqueos mediante registros de escritura anticipada (WAL), que se pueden reproducir cuando el servidor de Prometheus se reinicia después de un bloqueo. El archivo de registro de escritura anticipada wal se almacena en el directorio en segmentos de 128 MB. Estos archivos contienen datos brutos sin comprimir, por lo que son mucho más grandes que los archivos de bloques normales.
Prometheus mantendrá al menos 3 archivos de registro de escritura anticipada, pero los servidores de alto tráfico pueden ver más de tres archivos WAL porque necesita mantener al menos dos horas de datos originales.
La estructura de directorios del directorio de datos del servidor Prometheus es la siguiente:
./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│ └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98
│ ├── chunks
│ │ └── 000001
│ ├── tombstones
│ ├── index
│ └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│ └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD
│ ├── chunks
│ │ └── 000001
│ ├── tombstones
│ ├── index
│ └── meta.json
├── chunks_head
│ └── 000001
└── wal
├── 000000002
└── checkpoint.00000001
└── 00000000
Tenga en cuenta que la limitación del almacenamiento local es que no está agrupado ni replicado. Por lo tanto, no es arbitrariamente escalable ni duradero frente a interrupciones del disco o del nodo, y debe tratarse como cualquier otro tipo de base de datos de un solo nodo. Se recomienda usar RAID para mejorar la disponibilidad del disco, usar instantáneas para respaldo, planificación de capacidad, etc. para mejorar la durabilidad. Con una planificación y una durabilidad de almacenamiento adecuadas, se pueden almacenar muchos años de datos en el almacenamiento local.
Alternativamente, el almacenamiento externo se puede utilizar a través de la API de lectura / escritura remota. Estos sistemas varían mucho en durabilidad, rendimiento y eficiencia, por lo que se requiere una evaluación cuidadosa.
Para obtener información más detallada sobre el formato de archivo, consulte Formato TSDB.
Compactación
Los primeros bloques de dos horas eventualmente se comprimirán en bloques más largos en segundo plano.
La compresión creará bloques más grandes, hasta el 10% del tiempo de retención, o 31 días, lo que sea menor.
Aspectos operacionales
Prometheus tiene varios indicadores que permiten configurar el almacenamiento local. lo más importante es:
--storage.tsdb.path：这确定Prometheus在何处写入其数据库。默认为data/。
--storage.tsdb.retention.time：这确定何时删除旧数据。默认为15d。storage.tsdb.retention如果此标志设置为默认值以外的其他值，则覆盖。
--storage.tsdb.retention.size：[EXPERIMENTAL]这确定存储块可以使用的最大字节数（请注意，这不包括WAL大小，这可能是很大的）。最旧的数据将首先被删除。默认为0或禁用。该标志是实验性的，可以在将来的版本中进行更改。支持的单位：B，KB，MB，GB，TB，PB，EB。例如：“ 512MB”
--storage.tsdb.retention：已弃用该标志，而推荐使用storage.tsdb.retention.time。
--storage.tsdb.wal-compression：此标志启用预写日志（WAL）的压缩。根据您的数据，您可以预期WAL大小将减少一半，而额外的CPU负载却很少。此标志在2.11.0中引入，默认情况下在2.20.0中启用。请注意，一旦启用，将Prometheus降级到2.11.0以下的版本将需要删除WAL。
En promedio, Prometheus usa solo alrededor de 1-2 bytes por muestra. Por lo tanto, para planificar la capacidad del servidor Prometheus, se puede utilizar la siguiente fórmula aproximada:
needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample
Para ajustar la tasa de muestras tomadas por segundo, puede reducir la cantidad de series de tiempo capturadas (menos objetivos o menos secuencias por objetivo) o puede aumentar el intervalo de captura. Sin embargo, dado que las muestras de la secuencia están comprimidas, reducir el número de secuencias puede ser más eficaz.
Si su almacenamiento local está dañado por algún motivo, la mejor opción es cerrar Prometheus y eliminar todo el directorio de almacenamiento. Puede intentar eliminar un solo directorio de bloque o directorio WAL para resolver este problema, lo que significa que la ventana de tiempo perdido para cada directorio de bloque es de aproximadamente dos horas. Asimismo, el almacenamiento local de Prometheus no significa un almacenamiento duradero a largo plazo.
Nota: el almacenamiento local de Prometheus no admite sistemas de archivos que no sean compatibles con POSIX, ya que pueden producirse daños irrecuperables. El sistema de archivos NFS (incluido AWS EFS) no es compatible. NFS puede cumplir con POSIX, pero la mayoría de las implementaciones no lo son. Se recomienda encarecidamente utilizar un sistema de archivos local para mejorar la confiabilidad.
Si se especifican políticas de retención de tiempo y tamaño, se utilizará la primera política activada en ese momento.
La eliminación de bloques vencidos se realizará en el plan de fondo. Puede llevar hasta dos horas eliminar los bloques caducados. Los bloques vencidos deben estar completamente vencidos antes de ser borrados.
Integración de almacenamiento remoto
El almacenamiento local de Prometheus está limitado por un solo nodo en términos de escalabilidad y durabilidad. Prometheus no intenta resolver el almacenamiento en clúster en el propio Prometheus, sino que proporciona un conjunto de interfaces que permiten la integración con sistemas de almacenamiento remoto.
Visión general
Prometheus se integra con los sistemas de almacenamiento remoto de dos formas:
Prometheus puede escribir las muestras extraídas en la URL remota en un formato estándar.
Prometheus puede leer (devolver) datos de muestra de URL remotas en un formato estandarizado.
Arquitectura de lectura y escritura remota
Tanto los protocolos de lectura como los de escritura utilizan codificación de búfer de protocolo de compresión rápida basada en HTTP. El protocolo aún no se considera una API estable, y cuando es seguro asumir que todos los saltos entre Prometheus y el almacenamiento remoto admiten HTTP / 2, el protocolo puede cambiarse para usar gRPC sobre HTTP / 2 en el futuro.
Para obtener detalles sobre la configuración de la integración de almacenamiento remoto en Prometheus, consulte las secciones "Escritura remota" y "Lectura remota" del documento de configuración de Prometheus.
Para obtener más información sobre los mensajes de solicitud y respuesta, consulte Definición de búfer de protocolo de almacenamiento remoto.
Tenga en cuenta que en la ruta de lectura, Prometheus solo obtiene un conjunto de datos de serie sin procesar del selector de etiquetas y el rango de tiempo desde el extremo remoto. Todas las evaluaciones de los datos originales por PromQL todavía se están realizando en Prometheus. Esto significa que las consultas de lectura remota tienen ciertas limitaciones de escalabilidad, porque todos los datos necesarios deben cargarse en el servidor Prometheus consultado antes de procesarse allí. Sin embargo, por el momento, no es posible admitir la evaluación completamente distribuida de PromQL.
Integración existente
Para obtener más información sobre las integraciones existentes con sistemas de almacenamiento remoto, consulte la documentación de integración.