loki-s3存储
胡图图不涂涂
|
|
982
|
日志

3562 字
|
54 分钟
本文最后更新于 757 天前，其中的信息可能已经有所发展或是发生改变

loki

配置文件

1、Loki 的配置文件非常复杂，配置起来有一定难度，所以我们非常有必要对 Loki 配置文件进行专门的分析。Loki 配置文件 loki.yaml 支持的内容和默认值数据

# 用逗号分隔组件列表运行，默认的值 all 运行 Loki 在单个二进制文件中。
# 值 read 是一个别名，用于仅在同一进程中运行与读取路径相关的组件，如 querier 和 query-frontend。
# 值 write 同样是一个别名，用于仅在同一进程中运行与写路径相关的组件，如 ingester 和 distributor。
# 支持的值包括：all, compactor, distributor, ingester, querier, query-scheduler,
#  ingester-querier, query-frontend, index-gateway, ruler, table-manager, read, write。
# 当使用 `-list-target` 命令行标志运行 Loki 时，可以打印可用目标的完整列表。
[target: <string> | default = "all"]

# 通过 X-Scope-OrgID Header 启用身份验证，如果为 true，该 Header 必须存在。
# 如果为 false，OrgID 将始终设置为 "fake"。
[auth_enabled: <boolean> | default = true]

[ballast_bytes: <int> | default = 0]

# 配置已启动服务的 HTTP 和 gRPC 服务器通信。
[server: <server>]

# 配置 distributor。
[distributor: <distributor>]

# 配置 querier，仅在运行所有模块或 querier 时适用。
[querier: <querier>]

# query_scheduler 块配置 Loki 查询调度程序。
# 配置后，它将租户查询队列与查询前端分离
[query_scheduler: <query_scheduler>]

# 配置 Loki query-frontend 模块
[frontend: <frontend>]

# 在 Loki query-frontend 配置查询分割和缓存。
[query_range: <query_range>]

# 配置 Loki ruler 模块
[ruler: <ruler>]

# 配置 distributor 如何连接到 ingester。
# 仅在运行所有组件、distributor 或 querier 时适用。
[ingester_client: <ingester_client>]

# 配置 ingester 以及 ingester 如何将自己注册到 kv 存储。
[ingester: <ingester>]

# 配置 Loki 存储数据的地方
[storage_config: <storage_config>]

# 配置 Loki 在指定的存储中如何存储数据
[chunk_store_config: <chunk_store_config>]

# 配置 chunk 索引 schema 和存储的位置
[schema_config: <schema_config>]

# 配置 compactor 组件，该组件压缩索引分片以提高性能
[compactor: <compactor>]

# 配置每个租户或全局的限制
[limits_config: <limits_config>]

# 配置在 Loki querier 中运行的 worker - 拾取并执行查询前端排队的查询。
[frontend_worker: <frontend_worker>]

# 配置用于保留的 table manager。
[table_manager: <table_manager>]

# 配置 runtime config 模块，负责重新加载运行时配置文件。
[runtime_config: <runtime_config>]

# 配置 tracing
[tracing: <tracing>]

# 多个模块之间共享的通用配置。
# 如果在其他部分中给出了更具体的配置，则将忽略此部分中的相关配置。
[common: <common>]

# 使用情况报告的配置
[analytics: <analytics>]

common

  • 通用配置块 common 是由不同组件共享的公共定义，这样，就不必在多个地方重复配置了，下面是该配置块的相关属性：
# 不同 Loki 组件使用的公共存储配置
[storage: <storage>]

# 定义后，指定前缀将出现在端点路径的前面
[path_prefix: <string>]

# 传入的数据应该被复制到 ingester 组件多少次
[replication_factor: <int> | default = 3]

# 如果为 true，则 ingester、compactor 和 query_scheduler 的 ring tokens 将保存到 path_prefix 目录中的文件中。如果将其设置为 true 且 path_prefix 前缀为空，Loki 将出错。
[persist_tokens: <boolean>: default = false]

# 用于内部查找地址的通用的网络接口列表。
# 如果设置了更具体的 "instance_interface_names"，则忽略此选项。
# 如果在公共的 ring 模块下配置了 "instance_interface_names"，则该通用配置 "instance_interface_names" 只适用于前端，而不适用于与 ring 相关的组件（比如：distributor、ruler 等等）
[instance_interface_names: <list of string> | default = [<private network interfaces>]]

# Loki 组件用于暴露其地址的公共地址。
# 如果配置了更具体的 "instance_addr" 地址，该配置会被忽略。
# 如果 "instance_addr" 在公共 ring 部分下配置了，则该通用 "instance_addr" 配置只适用于前端，而不适用于与 ring 相关的组件（比如：distributor、ruler 等等）。
[instance_addr: <string>]

# 所有 Loki rings 使用的通用 ring 配置。
# 如果指定了通用的 ring 环，则其值用于定义任何未定义的 ring 值。
# 例如，你可以期望 distributor 的 ring 环使用公共部分中定义的 `heartbeat_period`，但前提是 distributor 的 ring 本身没有配置 `heartbeat_period`。
[ring: <ring>]
  • 上面的通用配置块中有一个 storage 的配置项，用来定义 Loki 不同组件使用的公共存储配置。如果在配置文件的其他位置提供了对象存储客户端的任何特定配置，则该特定配置将取代通用存储配置，对应的属性如下所示
# azure 配置
[azure: <azure_storage_config>]

# gcs 配置
[gcs: <gcs_storage_config>]

# s3 配置
[s3: <s3_storage_config>]

# swift 配置
[swift: <swift_storage_config>]

# 配置一个（本地）文件系统
[filesystem: <filesystem>]

[hedging: <hedging_config>]

storage_config

  • Loki 的存储引擎配置，这个配置块里面主要定义的是各类存储的一些基本信息。如下所示
# 在 AWS 中的 chunks 存储的配置。必需的选项只有在 aws 出现时才需要。
aws:
  # S3 或 S3 兼容的 endpoint URL 地址，带有编码的 Key 和 Secret。
  # 如果仅将 region 配置为主机，则将推断出正确的端点。
  # CLI flag: -s3.url
  [s3: <string>]

  # 设置为 true 可强制请求使用 path-style 寻址
  # CLI flag: -s3.force-path-style
  [s3forcepathstyle: <boolean> | default = false]

  # 以逗号分隔的 buckets 名称列表，用于均匀分布 chunks。
  # 在 s3.url 标志中覆盖任意的 buckets
  # CLI flag: -s3.buckets
  [bucketnames: <string> | default = ""]

  # 连接的 S3 Endpoint
  # CLI flag: -s3.endpoint
  [endpoint: <string> | default = ""]

  # AWS 使用的区域
  # CLI flag: -s3.region
  [region: <string> | default = ""]

  # AWS Access Key ID.
  # CLI flag: -s3.access-key-id
  [access_key_id: <string> | default = ""]

  # AWS Secret Access Key.
  # CLI flag: -s3.secret-access-key
  [secret_access_key: <string> | default = ""]

  # 禁用 https
  # CLI flag: -s3.insecure
  [insecure: <boolean> | default = false]

  # 启用 AES256 AWS 服务器端加密
  # CLI flag: -s3.sse-encryption
  [sse_encryption: <boolean> | default = false]

  # ... 省略其他配置

  # 配置 DynamoDB 连接
  dynamodb:
    # DynamoDB URL 地址
    # CLI flag: -dynamodb.url
    dynamodb_url: <string>
    # ...... 省略 dynamodb 配置

# 在 Bigtable 中配置存储索引。只有在配置中定义了 bigtable 时，才需要必填字段。
bigtable:
  # BigTable project ID
   # CLI flag: -bigtable.project
  project: <string>

  # BigTable instance ID
  # CLI flag: -bigtable.instance
  instance: <string>

  # 配置连接到 Bigtable 的 gRPC 客户端
  [grpc_client_config: <grpc_client_config>]

# 配置存储 chunks 在 GCS 中，只有在配置中定义了 gcs 时才需要该字段
gcs:
  # 要放入 chunks 的 GCS 存储桶的名称。
  # CLI flag: -gcs.bucketname
  bucket_name: <string>

  # GCS客户端用于每个 PUT 请求的缓冲区大小，0表示禁用 buffer。
  # to disable buffering.
  # CLI flag: -gcs.chunk-buffer-size
  [chunk_buffer_size: <int> | default = 0]

  # 对 GCS 的请求超时的时间。
  # CLI flag: -gcs.request-timeout
  [request_timeout: <duration> | default = 0s]

# 在 Cassandra 中存储 chunks 和/或 索引的配置
cassandra:
  # 用逗号分隔的 Cassandra 实例的主机名或 IPs
  # CLI flag: -cassandra.addresses
  addresses: <string>
  # cassandra 端口
  # CLI flag: -cassandra.port
  [port: <int> | default = 9042]

  # ...... 省略

swift:
#   ...... 省略

# 存储索引在 BoltDB 中的配置。
boltdb:
  # BoltDB 索引文件路径
  # CLI flag: -boltdb.dir
  directory: <string>

# 存储 chunks 在本地文件系统
filesystem:
  # chunks 存储的路径
  # CLI flag: -local.chunk-directory
  directory: <string>

# 以 boltdb 文件的形式在对象存储（GCS/S3/Azure/Swift/Filesystem）中配置存储索引。
boltdb_shipper:
  # ingesters 将数据写入 boltdb 文件的目录，然后由 shipper 上传到配置的存储中
  # CLI flag: -boltdb.shipper.active-index-directory
  [active_index_directory: <string> | default = ""]

  # 用于保存 boltdb 文件的共享存储，支持的类型有：gcs、s3、azure、filesystem
  # CLI flag: -boltdb.shipper.shared-store
  [shared_store: <string> | default = ""]

  # 用于恢复查询的 boltDB 文件的缓存位置
  # CLI flag: -boltdb.shipper.cache-location
  [cache_location: <string> | default = ""]

  # 查询缓存中恢复的 boltDB 文件的 TTL
  # CLI flag: -boltdb.shipper.cache-ttl
  [cache_ttl: <duration> | default = 24h]

  # 将下载的文件与存储重新同步的频率
  # CLI flag: -boltdb.shipper.resync-interval
  [resync_interval: <duration> | default = 5m]

  # 为查询保留下载索引的天数，仅适用于以24小时周期创建的表。
  # CLI flag: -boltdb.shipper.query-ready-num-days
  [query_ready_num_days: <int> | default = 0]

  index_gateway_client:
    # Index Gateway gRPC 服务地址
    # CLI flag: -boltdb.shipper.index-gateway-client.server-address
    [server_address: <string> | default = ""]
    # 连接 Index Gateway gRPC 服务的 gRPC 客户端
    [grpc_client_config: <grpc_client_config>]

# 活跃索引的缓存有效期，不应高于 ingester 设置中的 `chunk_idle_period`。
# CLI flag: -store.index-cache-validity
[index_cache_validity: <duration> | default = 5m]

# 每批获取的最大 chunks 数。
# CLI flag: -store.max-chunk-batch-size
[max_chunk_batch_size: <int> | default = 50]

# 配置如何构建索引查询的缓存。
index_queries_cache_config: <cache_config>

distributor

  • distributor 配置块用于配置 distributor 组件，该配置块对应的属性有：
# 配置 distributors ring，在启用 "global" 摄取率策略时使用。
ring:
  kvstore:
    # ring 使用的后端存储，支持的值包括：consul、etcd、inmemory、memberlist
    # memberlist 使用的是 gossip 协议来让集群内的所有节点达到最终一致性的
    # CLI flag: -distributor.ring.store
    store: <string>

    # 存储中 key 的前缀， 应以 `/` 结尾。
    # CLI flag: -distributor.ring.prefix
    [prefix: <string> | default = "collectors/"]

    # Consul 客户端配置，只有当 store 配置为 `consul` 的时候才适用
    # 此块配置的 CLI 标志前缀为：distributor.ring
    [consul: <consul_config>]

    # ETCD v3 客户端配置，只有当 store 配置为 `etcd` 的时候才适用
    # 此块配置的 CLI 标志前缀为：distributor.ring
    [etcd: <etcd_config>]

  # 心跳超时，在此超时之后，ring 内的 distributor 被视为不健康，0表示never
  # CLI flag: -distributor.ring.heartbeat-timeout
  [heartbeat_timeout: <duration> | default = 1m]

querier

  • querier 配置块用于配置 querier 组件，包含的属性有：
# 在执行查询请求期间查询 ingesters 或存储的超时时间。
# CLI flag: -querier.query-timeout
[query_timeout: <duration> | default = 1m]

# 为实时跟踪请求提供服务的最长持续时间。
# CLI flag: -querier.tail-max-duration
[tail_max_duration: <duration> | default = 1h]

# 发送超过最小成功查询请求之前的等待时间。
# CLI flag: -querier.extra-query-delay
[extra_query_delay: <duration> | default = 0s]

# 最大回溯期，超过该值，查询不会发送到 ingester。
# 0 意味着所有的 queries 被发送到 ingester。
# CLI flag: -querier.query-ingesters-within
[query_ingesters_within: <duration> | default = 3h]

# 允许的最大并发查询数
# CLI flag: -querier.max-concurrent
[max_concurrent: <int> | default = 10]

# 仅查询存储中的数据，不尝试查询任何 ingesters
# CLI flag: -querier.query-store-only
[query_store_only: <boolean> | default = false]

# 是否允许查询多个租户
# CLI flag: -querier.multi-tenant-queries-enabled
[multi_tenant_queries_enabled: <boolean> | default = false]

# LogQL 引擎配置选项
engine:
  # 查询执行超时时间
  # CLI flag: -querier.engine.timeout
  [timeout: <duration> | default = 3m]

  # 查找日志行的最长时间，仅适用于即时日志查询。
  # CLI flag: -querier.engine.max-lookback-period
  [max_look_back_period: <duration> | default = 30s]

query_range

  • 用于在 Loki 查询前端配置查询分割和缓存。
# 不推荐: 按日拆分查询并行执行。
# 用 -querier.split-queries-by-interval 代替.
# CLI flag: -querier.split-queries-by-day
[split_queries_by_day: <boolean> | default = false]

# 对传入查询进行变更，使其开始和结束与其步长保持一致。
# CLI flag: -querier.align-querier-with-step
[align_queries_with_step: <boolean> | default = false]

results_cache:  # 缓存
  cache: <cache_config>

# 缓存查询结果
# CLI flag: -querier.cache-results
[cache_results: <boolean> | default = false]

# 单个请求的最大重试次数
# CLI flag: -querier.max-retries-per-request
[max_retries: <int> | default = 5]

# 根据存储分片配置执行查询并行化，并查询AST。此功能仅由 chunks 存储引擎支持。
# CLI flag: -querier.parallelise-shardable-queries
[parallelise_shardable_queries: <boolean> | default = true]

schema_config

  • 这里面主要定义的是 Loki 数据存储的策略，从默认的配置里面可以得到的信息是 Loki 里面保存的是2018年4月15日之后的数据，同时原始文件（chunks）存在 filesystem 中，index 存在 boltdb 当中且保存的周期是168小时
# 用于 chunk 索引 schemas 配置
configs:
- [<period_config>]
  • 其中就包含一个 period_config 列表，该配置块用于配置从特定的时间段应该使用哪些索引模式
# 应该创建索引 buckets 的第一天的日期。
# 如果这是唯一的 `period_config`，则使用过去的日期，否则在希望模式切换时使用日期。
# YYYY-MM-DD 格式, 例如: 2018-04-15.
[from: <daytime>]

# 下面的 store 和 object_store 会决定使用哪个 <storage_config> key。

# 用于索引的存储：aws、aws-dynamo、gcp、bigtable、bigtable-hashed、cassandra、boltdb 或者 boltdb-shipper。
store: <string>

# 用于 chunks 的存储：aws、azure、gcp、bigtable、gcs、cassandra、swift 或者 filesystem
# 如果省略，则默认为与 store 相同的值。
[object_store: <string>]

# schema 使用的版本
schema: <string>

# 配置索引如何更新和存储
index:
  # 所有周期表的表前缀。
  prefix: <string>
  # Table 周期.
  [period: <duration> | default = 168h]
  # 要添加到所有管理的表中的标签。
  tags:
    [<string>: <string> ...]

# 配置 chunks 的更新和存储方式。
chunks:
  prefix: <string>
  [period: <duration> | default = 168h]
  tags:
    [<string>: <string> ...]

# 将创建多少个分片。仅当 schema 为 v10 或更高版本时使用。
[row_shards: <int> | default = 16]
  • Loki 对于数据存储的目标是向后兼容，通过修改 Schema 配置允许以增量方式升级到新的存储模式。首先，我们需要在schema_config 中创建一个新的 configs 条目，要记住的是新加的存储模式起始时间必须是将来的某个时间点，这样 Table Manager 就可以在之前创建所需的表，并确保不会查询现有数据。否则在查询时会因丢失旧的日志索引造成无法检索。例如我们要把2022年6月18日之后的 Loki 日志切换到 cassandra 和 S3 上，那么按照如下配置后，重启服务即可
schema_config:
  configs:
  - from: 2018-04-15
    store: boltdb
    object_store: filesystem
    schema: v10
    index:
      prefix: index_
      period: 168h
  - from: 2022-06-18
    store: cassandra
    object_store: aws
    schema: v11
    index:
      prefix: index_
      period: 720h
    chunks:
      prefix: chunks_
      period: 720h
storage_config:
  boltdb:
    directory: /data/loki/index
  filesystem:
    directory: /data/loki/chunks
  cassandra:
    username: cassandra
    password: cassandra
    addresses: cassandra
    auth: true
    keyspace: lokiindex
  aws:
    s3: s3://<accessKey>:<secretKey>@<s3_url>/<buckets>
    s3forcepathstyle: true
  • 上面的配置意思就是对于2022年6月18日之前保存的所有数据，Loki 使用 v10 的 schema，到点之后就采用 v11 的 schema 策略来存储日志

cache_config

  • cache_config 块用来配置 Loki 将如何缓存 requests、chunks 和索引到一个后端缓存存储中去
# 开启内存缓存
# CLI flag: -<prefix>.cache.enable-fifocache
[enable_fifocache: <boolean>]

# 缓存的默认有效期（除非重写）。
# CLI flag: -<prefix>.default-validity
[default_validity: <duration>]

# 在使用 memcached 时配置后台缓存
background:
  # 有多少 goroutines 用来写回 memcached。
  # CLI flag: -<prefix>.background.write-back-concurrency
  [writeback_goroutines: <int> | default = 10]

  # 后台写回 memcached 需要缓存多少 chunks。
  # CLI flagL -<prefix>.background.write-back-buffer
  [writeback_buffer: <int> = 10000]

# 配置 memcached
memcached:
  # 配置 memcached 中的 key 有效期
  # CLI flag: -<prefix>.memcached.expiration
  expiration: <duration>

  # 配置每个批处理请求中要获取的 keys 数量。
  # CLI flag: -<prefix>.memcached.batchsize
  batch_size: <int> | default = 1024

  # 对 memcached 的最大活动请求数。
  # CLI flag: -<prefix>.memcached.parallelism
  [parallelism: <int> | default = 100]

# 配置如何连接到一个或多个 memcached 服务器
memcached_client:
  # 缓存 chunks 时用于 memcached 服务的主机名。
  # 如果为空，没有 memcached 会被使用。将使用 SRV 查找。
  # CLI flag: -<prefix>.memcached.hostname
  [host: <string>]

  # 用于发现 memcached 服务器的 SRV 服务。
  # CLI flag: -<prefix>.memcached.service
  [service: <string> | default = "memcached"]

  # (实验性的) DNS 服务发现地址列表(逗号分隔)
  # https://cortexmetrics.io/docs/configuration/arguments/#dns-service-discovery
  # CLI flag: -<prefix>.memcached.addresses
  [addresses: <string> | default = ""]

  # memcached 请求超时时间
  # CLI flag: -<prefix>.memcached.timeout
  [timeout: <duration> | default = 100ms]

  # memcached 客户端池中的最大空闲连接数。
  # CLI flag: -<prefix>.memcached.max-idle-conns
  [max_idle_conns: <int> | default = 16]

  # 轮询 memcached 服务器的 DNS 的时间间隔。
  # CLI flag: -<prefix>.memcached.update-interval
  [update_interval: <duration> | default = 1m]

  # 是否使用一致哈希来发现多个 memcached 服务器。
  # CLI flag: -<prefix>.memcached.consistent-hash
  [consistent_hash: <boolean> | default = true]

  # CLI flag: -<prefix>.memcached.max-item-size
  [max_item_size: <int> | default = 0]
  # ...... 省略

redis:
  # 用于缓存的 Redis Server 或 Cluster 配置
  # CLI flag: -<prefix>.redis.endpoint
  [endpoint: <string>]
  # ...... 省略

fifocache:
  # 最大缓存大小（bytes）
  # CLI flag: -<prefix>.fifocache.max-size-bytes
  [max_size_bytes: <string> | default = "1GB"]

  # 最多缓存多少 items
  # CLI flag: -<prefix>.fifocache.max-size-items
  [max_size_items: <int> | default = 0]

  # 缓存有效期
  # The value of 0 disables auto-expiration.
  # CLI flag: -<prefix>.fifocache.ttl
  [ttl: <duration> | default = 1h]

table_manager

  • Table Manager 是 Loki的一个组件，主要负责在其时间段开始之前创建周期表，并在其数据时间范围超出保留期限时将其删除。它当前支持的后端包含如下
# 用于表容量更新的主“关闭开关”，例如故障排除时。
# CLI flag: -table-manager.throughput-updates-disabled
[throughput_updates_disabled: <boolean> | default = false]

# 用于表保留删除的主开关
# CLI flag: -table-manager.retention-deletes-enabled
[retention_deletes_enabled: <boolean> | default = false]

# 在删除表之前，它们将保留多长时间，0s表示禁用删除。
# 保留期必须是 index / chunks 表 "period" 的倍数。
# CLI flag: -table-manager.retention-period
[retention_period: <duration> | default = 0s]

# 表管理器轮询表的时间间隔。
# CLI flag: -table-manager.poll-interval
[poll_interval: <duration> | default = 2m]

# 在需要创建表之前的持续时间。
# CLI flag: -table-manager.periodic-table.grace-period
[creation_grace_period: <duration> | default = 10m]

# 配置 DynamoDB 索引表。
# The CLI flags prefix for this block config is: table-manager.index-table
index_tables_provisioning: <provision_config>

# 配置 DynamoDB chunk 表。
# The CLI flags prefix for this block config is: table-manager.chunk-table
chunk_tables_provisioning: <provision_config>

1、默认情况下，原始日志文件除了使用 filesystem 的存储有周期删除旧日志文件外，Loki 的其他 chunk 存储均不会删除旧日志文件 ，如果你的日志原始文件存储在 S3 上，那么我们可以直接找到旧的文件删除，这个动作仅仅只会影响我们查询不到这个时间区域的日志内容。如果你的 Loki 存储用了 table-based 的存储服务，那么日志的留存策略就会受到 Table Manager 的节制，它当前支持的后端包含如下

  • Index 日志索引
  • Amazon DynamoDB
  • Google Bigtable
  • Apache Cassandra
  • BoltDB (主要用于本地环境)
  • Chunk 日志原始文件
  • Amazon DynamoDB
  • Google Bigtable
  • Apache Cassandra
  • Filesystem (主要用于本地环境)

2、由于具有破坏性，默认情况下 Table Manager 功能被禁用，我们可以在配置中显式启用数据删除策略并将其保留期设置为大于0

table_manager:
  retention_deletes_enabled: true
  retention_period: 336h

部署配置

1、yaml

version: '3'
services:
  loki:
    image: grafana/loki:latest
    container_name: loki_loki
    restart: always
    user: root
    ports:
      - 3100:3100
    volumes:
      - /mydata/loki/conf:/etc/loki
      - /mydata/loki/db:/loki
      - /mydata/loki/log:/var/log
      - /etc/localtime:/etc/localtime
    command: -config.file=/etc/loki/local-config.yaml
  promtail:
    image: grafana/promtail:latest
    container_name: loki_promtail
    restart: always
    user: root
    volumes:
      - /mydata/loki/promtail:/etc/promtail
      - /var/log:/mydata
      - /etc/localtime:/etc/localtime
    command:
      -config.file=/etc/promtail/config.yml
networks:
  default:
    external:
      name: prom_net

Promtail

配置文件

1、Promtail 是 Loki 官方支持的日志采集端，在需要采集日志的节点上运行采集代理，再统一发送到 Loki 进行处理。除了使用 Promtail，社区还有很多采集日志的组件，比如 fluentd、fluent bit、logstash 等，也都支持发送到 Loki

  • Promtail 是负责收集日志发送给 loki 的代理程序。Promtail 默认通过一个 config.yaml 文件进行配置，其中包含 Promtail 服务端信息、存储位置以及如何从文件中抓取日志等配置
  • 要指定加载哪个配置文件，只需要在命令行下通过 -config.file 参数传递 YAML 配置文件即可。此外我们还可以通过在配置文件中使用环境变量引用来设置需要的配置，但是需要在命令行中配置 -config.expand-env=true
  • 然后可以使用 ${VAR} 来配置，其中 VAR 是环境变量的名称，每个变量的引用在启动时被环境变量的值替换，替换是区分大小写的，而且在 YAML 文件被解析之前发生，对未定义变量的引用将被替换为空字符串，除非你指定了一个默认值或自定义的错误文本，要指定一个默认值
${VAR:default_value}
  • 其中 default_value 是在环境变量未定义的情况下要使用的默认值。
  • 默认的 config.yaml 配置文件支持的内容格式为：
# 配置 Promtail 服务端
[server: <server_config>]

# 描述 Promtail 如何连接到 Loki 的多个实例，向每个实例发送日志。
# 发送是在单线程上完成的!
# 如果你想向多个远程 Loki 实例发送，一般建议并行运行多个 promtail 客户端。
client: <client_config>

# 描述了如何将读取的文件偏移量保存到磁盘上
[positions: <position_config>]

# 抓取日志配置
scrape_configs:
  - [<scrape_config>]

# 配置被 watch 的目标如何 tailed
[target_config: <target_config>]

server

  • server 属性配置 Promtail 作为 HTTP 服务器的行为
# 禁用 HTTP 和 GRPC 服务
[disable: <boolean> | default = false]

# HTTP 服务监听的主机
[http_listen_address: <string>]

# HTTP 服务监听的端口（0表示随机）
[http_listen_port: <int> | default = 80]

# gRPC 服务监听主机
[grpc_listen_address: <string>]

# gRPC 服务监听的端口（0表示随机）
[grpc_listen_port: <int> | default = 9095]

# 注册指标处理器
[register_instrumentation: <boolean> | default = true]

# 优雅退出超时时间
[graceful_shutdown_timeout: <duration> | default = 30s]

# HTTP 服务读取超时时间
[http_server_read_timeout: <duration> | default = 30s]

# HTTP 服务写入超时时间
[http_server_write_timeout: <duration> | default = 30s]

# HTTP 服务空闲超时时间
[http_server_idle_timeout: <duration> | default = 120s]

# 可接收的最大 gRPC 消息大小
[grpc_server_max_recv_msg_size: <int> | default = 4194304]

# 可发送的最大 gRPC 消息大小
[grpc_server_max_send_msg_size: <int> | default = 4194304]

# 对 gRPC 调用的并发流数量的限制 (0 = unlimited)
[grpc_server_max_concurrent_streams: <int> | default = 100]

# 只记录给定严重程度或以上的信息，支持的值：[debug, info, warn, error]
[log_level: <string> | default = "info"]

# 所有 API 路由服务的基本路径(e.g., /v1/).
[http_path_prefix: <string>]

# 目标管理器检测 promtail 可读的标志，如果设置为 false 检查将被忽略
[health_check_target: <bool> | default = true]

positions

  • positions 属性配置了 Promtail 保存文件的位置，表示它已经读到了日志文件的什么位置。当 Promtail 重新启动时需要它，以允许它从中断的地方继续读取日志
# positions 文件的路径
[filename: <string> | default = "/var/log/positions.yaml"]

# 更新 positions 文件的周期
[sync_period: <duration> | default = 10s]

# 是否忽略并覆盖被破坏的 positions 文件
[ignore_invalid_yaml: <boolean> | default = false]

scrape_configs

  • scrape_configs 配置了 Promtail 如何使用指定的发现方法从一系列目标中抓取日志，类似于 Prometheus 中的抓取配置
# 任务名称，用于在 Promtail 中识别该抓取配置的名称。
job_name: <string>

# 描述如何对目标日志进行结构化
[pipeline_stages: <pipeline_stages>]

# 如何从 jounal 抓取日志
[journal: <journal_config>]

# 如何从 syslog 抓取日志
[syslog: <syslog_config>]

# 如何通过 Loki push API 接收日志 (例如从其他 Promtail 或 Docker Logging Driver 中获取的数据)
[loki_push_api: <loki_push_api_config>]

# 描述了如何 relabel 目标
relabel_configs:
  - [<relabel_config>]

# 抓取日志静态目标配置
static_configs:
  - [<static_config>]

# 包含要抓取的目标文件
file_sd_configs:
  - [<file_sd_configs>]

# 基于kubernetes的自动发现配置
kubernetes_sd_configs:
  - [<kubernetes_sd_config>]

Label 标签

  • Label 标签是一个键值对，可以定义任何东西，我们喜欢称它们为描述日志流的元数据。如果你熟悉 Prometheus，那么一定对 Label 标签有一定的了解，在 Loki 的 scrape 配置中也定义了这些标签，和 Prometheus 拥有一致的功能，这些标签非常容易将应用程序指标和日志数据关联起来
  • Loki 中的标签执行一个非常重要的任务：它们定义了一个流。更具体地说，每个标签键和值的组合定义了流。如果只是一个标签值变化，这将创建一个新的流
  • 如果你熟悉 Prometheus，那里的术语叫序列，而且 Prometheus 中还有一个额外的维度：指标名称。Loki 中简化了这一点，因为没有指标名，只有标签，所以最后决定使用流而不是序列

1、首先看下下面的示例

scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: syslog
      __path__: /var/log/syslog
  • 这个配置将获取日志文件数据并添加一个 job=syslog 的标签，我们可以这样来查询：
{job="syslog"}
  • 这将在 Loki 中创建一个流。现在我们再新增一些任务配置：
scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: syslog
      __path__: /var/log/syslog 
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: apache
      __path__: /var/log/apache.log
  • 现在我们采集两个日志文件，每个文件有一个标签与一个值，所以 Loki 会存储为两个流。我们可以通过下面几种方式来查询这些流：
{job="apache"} -> 显示 job 标签为 apache 的日志
{job="syslog"} -> 显示 job 标签为 syslog 的日志
{job=~"apache|syslog"} -> 显示 job 标签为 apache 或者 syslog 的日志
  • 最后一种方式我们使用的是一个 regex 标签匹配器来获取 job 标签值为 apache 或者 syslog 的日志。接下来我们看看如何使用额外的标签：
scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: syslog
      env: dev
      __path__: /var/log/syslog 
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: apache
      env: dev
      __path__: /var/log/apache.log
  • 要获取这两个任务的日志可以用下面的方式来代替 regex 的方式：
{env="dev"} -> 将返回所有带有 env=dev 标签的日志
  • 通过使用一个标签就可以查询很多日志流了，通过组合多个不同的标签，可以创建非常灵活的日志查询
  • Label 标签是 Loki 日志数据的索引，它们用于查找压缩后的日志内容，这些内容被单独存储为块。标签和值的每一个唯一组合都定义了一个流 ，一个流的日志被分批，压缩，并作为块进行存储

收集docker日志

1、安装loki的docker plugin

docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions

2、当有新版本时, 更新plugins

docker plugin disable loki --force
docker plugin upgrade loki grafana/loki-docker-driver:latest --grant-all-permissions
docker plugin enable loki
systemctl restart docker

3、对于loki的docker plugin有两种使用方式

  • 配置daemon.json,收集此后创建的所有容器的日志(注意，是配置daemon.json后重启docker服务后创建的容器才会把日志输出到loki)
  • 新建容器时指定logging类型为loki，这样只有指定了logging的容器才会输出到loki

全局收集配置

1、编辑daemon.json。linux下默认路径是/etc/docker/daemon.json (需要sudo)， windows则默认是%userprofile%\.docker\daemon.json

{
  "log-driver": "loki",
  "log-opts": {
    "loki-url": "https://YOUR_IP:3100/loki/api/v1/push",
    "max-size": "50m",
    "max-file": "10",    "loki-pipeline-stages": "- multiline:\n      firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'\n"
  },
  "registry-mirrors": ["https://registry.docker-cn.com"]
}
  • 其中max-size表示日志文件最大大小，max-file表示最多10个日志文件，都是对单个容器来说的,    multiline是配置多行识别(默认最多128行),转为单行, firstline表示单条日志的首行正则表达式
  • 我的是 [03:00:32 INFO] 开头这种格式,所以对应正则是^\[\d{2}:\d{2}:\d{2} \w{4}\]  按照你自己的日志开头编写对应正则替换即可

2、然后重启docker服务

sudo systemctl restart docker
  • 在此之后创建的容器默认都会把日志发送到loki

run配置日志输出到loki

1、通过docker run启动容器，可以通过–log-driver来指定为loki。示例如下

docker run --rm --name=grafana --log-driver=loki --log-opt loki-url="https://YOUR_IP:3100/loki/api/v1/push" --log-opt max-size=50m --log-opt max-file=10 grafana/grafana

docker run -d --name=nginx -p 8989:80 --log-driver=loki  --log-opt loki-url="https://10.10.10.179:3100/loki/api/v1/push"  --log-opt max-size=50m --log-opt max-file=10 nginx:latest


--log-driver=loki指定日志驱动器为loki
--log-opt loki-url则指定了loki的url
--log-opt max-size日志最大大小
--log-opt max-file日志文件最大数量

2、docker-compose方式

  • docker-compose 小于3.4可以对需要日志输出的配置添加配置如下
logging:
  driver: loki
  options:
    loki-url: "https://YOUR_IP:3100/loki/api/v1/push"
    max-size: "50m"
    max-file: "10"    loki-pipeline-stages: |      - multiline:          firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'
  • 对于3.4及其以上版本可以通过定义模板来减少代码量
version: "3.4"

x-logging:
  &loki-logging
  driver: loki
  options:
    loki-url: "https://YOUR_IP:3100/loki/api/v1/push"
    max-size: "50m"
    max-file: "10"    loki-pipeline-stages: |      - multiline:          firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'

services:
  host:
    container_name: grafana
    image: grafana/grafana
    environment:
    - TZ=Asia/Shanghai
    - LANG=zh_CN.UTF-8
    logging: *loki-logging

minio存储

version: '3'
services:
  minio:
    image: minio/minio:latest
    container_name: minio
    restart: always
    user: root
    ports:
      - 9000:9000
      - 9090:9090
    command: server /data --address "0.0.0.0:9000" --console-address "0.0.0.0:9090"
    volumes:
      - /etc/localtime:/etc/localtime
      - /data/minio/conf:/root/.minio
      - /data/minio/db:/data
    environment:
      - 'MINIO_ROOT_USER=admin'
      - 'MINIO_ROOT_PASSWORD=Admin123!'
networks:
  default:
    external:
      name: minio_net

1、 注解

  • MINIO_ROOT_USER ：账号
  • MINIO_ROOT_PASSWORD ：密码（账号长度必须大于等于5，密码长度必须大于等于8位）

2、创建key

2、配置文件

auth_enabled: false
server:
  http_listen_port: 3100
common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory
schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h
storage_config:
  aws:
    s3: https://user:passwd@10.10.200.38:9000/***
    s3forcepathstyle: true
  boltdb_shipper:
    active_index_directory: /loki/boltdb-shipper-active
    cache_location: /loki/boltdb-shipper-cache
    cache_ttl: 1h
    shared_store: s3
ruler:
  alertmanager_url: https://localhost:9093

3、就好了url最后的***就是bucket的名字

oss存储

1、服务器尝试连接oss

wget https://gosspublic.alicdn.com/ossutil/1.7.14/ossutil64

chmod +x ossutil64
mv ossutil64 /usr/local/bin/

[root@ops-prometheus ~]# ossutil64 config
The command creates a configuration file and stores credentials.

Please enter the config file name,the file name can include path(default /root/.ossutilconfig, carriage return will use the default file. If you specified this option to other file, you should specify --config-file option to the file when you use other commands):
No config file entered, will use the default config file /root/.ossutilconfig

For the following settings, carriage return means skip the configuration. Please try "help config" to see the meaning of the settings
Please enter language(CH/EN, default is:EN, the configuration will go into effect after the command successfully executed):
Please enter endpoint:oss-cn-shanghai-internal.aliyuncs.com
Please enter accessKeyID:阿里云
Please enter accessKeySecret:阿里云
Please enter stsToken:
[root@ops-prometheus ~]# ossutil64 ls
CreationTime                                 Region    StorageClass    BucketName
2022-12-13 10:29:28 +0800 CST       oss-cn-shanghai        Standard    oss://360-loki
2020-08-21 15:54:03 +0800 CST       oss-cn-shanghai        Standard    oss://360aidata
2022-08-03 09:20:39 +0800 CST       oss-cn-shanghai              IA    oss://***-ops
2022-11-14 17:06:28 +0800 CST       oss-cn-shanghai        Standard    oss://nsfocus-vm
Bucket Number is: 4

0.119188(s) elapsed

2、配置文件

schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: aws
      schema: v11
      index:
        prefix: index_
        period: 24h
storage_config:
  aws:
    bucketnames: ***-loki
    endpoint: oss-cn-shanghai-internal.aliyuncs.com
    access_key_id: ********  
    secret_access_key: ******
#    region: oss-cn-shanghai                                             # 对象存储存储桶地域
  boltdb_shipper:
    active_index_directory: /loki/index
    shared_store: s3
    cache_location: /loki/boltdb-cache
asasa
博客内容均系原创，未经允许严禁转载！
暂无评论

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																					

							
							
						

										
					
											
						

	

		
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
（╯‵□′）╯︵┴─┴
￣﹃￣
(/ω＼)
∠( ᐛ 」∠)＿
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ｀)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ(￣∇￣o)
ヾ(´･ ･｀｡)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò｡)
Σ(っ °Д °;)っ
( ,,´･ω･)ﾉ"(´っω･｀｡)
╮(╯▽╰)╭
o(*////▽////*)q
＞﹏＜
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
	

	

		
颜文字
Emoji
小恐龙
花!
	


									

			

			
			
		

	






上一篇
下一篇 

                    

                    
			        推荐文章
		            

		            

							
Elasticearch集群and备份s3

							
							

							
Filebeat系列

							
							

							
ElastAlert2+ELK钉钉告警

							
							
 首页