loki-日志

一、loki

Github

• ELK虽然功能丰富，但规模复杂，资源占用高，操作苦难，很多功能往往用不上，loki 受 prometheus 启发的水平可扩展、高可用、多租户日志聚合系统，它的设计非常经济高效且易于操作，不对日志进行全文索引。而是为每个日志流建立一组标签，并通过存储压缩非结构化日志和索引元数据
• 特别适合存储 Kubernetes Pod 日志。Pod 标签等元数据会自动抓取并建立索引

1. 配置文件

参考一

• 配置文件说明

auth_enabled: false				# 通过 X-Scope-OrgID 标头启用身份验证，如果为 true，则必须存在。 如果为 false，则 OrgID 将始终设置为“ fake”，默认值：true

server:							# 用于配置 loki 提供 http 和 gRPC 这两种服务的行为
  http_listen_port: 3100		# Loki http 监听端口号为3100
  grpc_listen_port: 9096		# Loki grpc 监听端口号为3100

# 通用配置，从 2.4 版本开始，common 字段将会逐步代替其他描述不清晰的字段，比如 common.storage 将会代替 storage_cofig 字段
common:							# 通用配置，用于配置一些其他配置部分可以共享的配置，比如存储、优先级低，若其他部分指定了相同的配置，则该配置在对应的其他部分的配置将被忽略
  instance_addr: 127.0.0.1		# Loki 实例地址
  path_prefix: /tmp/loki		# Loki 路径前缀
  storage:						# 存储配置
    filesystem:
      chunks_directory: /tmp/loki/chunks
      rules_directory: /tmp/loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

query_range:
  results_cache:
    cache:
      embedded_cache:
        enabled: true			# 启用结果缓存
        max_size_mb: 100		# 缓存的最大大小（以MB为单位）

storage_config:
 boltdb_shipper:
    active_index_directory: /tmp/loki/boltdb-shipper-active		# 配置活动索引文件的存储目录为/tmp/loki/boltdb-shipper-active
    cache_location: /tmp/loki/boltdb-shipper-cache				# 配置BoltDB缓存文件的存储目录为/tmp/loki/boltdb-shipper-cache
    cache_ttl: 24				# 配置BoltDB缓存的TTL
    shared_store: s3			# 使用 s3 作为数据存储
 aws:
   s3: s3://admin:minio@0304@minio.yeemiao.net.cn/buckets/loki
   s3forcepathstyle: true


schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

ruler:
  alertmanager_url: http://localhost:9093	 # Alertmanager的URL
  
table_manager:					# 日志保存时长
  retention_deletes_enabled: true
  retention_period: 24h  		# 必须是24小时的倍数

案例配置文件

auth_enabled: false
 
server:
  http_listen_port: 3100     #如是云服务需打开3100端口
  grpc_listen_port: 9096
  grpc_server_max_recv_msg_size: 8388608
  grpc_server_max_send_msg_size: 8388608
 
ingester:
  lifecycler:
    address: 0.0.0.0      #监听地址,可不做修改。
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
    final_sleep: 0s
  chunk_idle_period: 5m
  chunk_retain_period: 30s
  max_transfer_retries: 0

ingester_client:
  remote_timeout: 2m

schema_config:
  configs:
    - from: 2023-01-29
      store: boltdb
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 168h
 
storage_config:
  boltdb:
    directory: /data/tools/Loki/data/index   #自定义boltdb目录(在loki目录下新建data文件来存放)
 
  filesystem:
    directory: /data/tools/Loki/data/chunks        #自定义filesystem目录(在loki目录下新建data文件来存放)
 
#positions:
#  filename: /data/tools/Loki/logs/loki-3100.log
#  rimestamp: utp
#  rotation:
#    max_age: 7d
#    max_size: 100MiB

limits_config:
  enforce_metric_name: false
  reject_old_samples: true
  reject_old_samples_max_age: 168h
  #ngestion_rate_strategy: local
  ingestion_rate_mb: 30
  ingestion_burst_size_mb: 60
  per_stream_rate_limit: 10MB
  per_stream_rate_limit_burst: 20MB
  max_query_length: 0h
 
chunk_store_config:
  max_look_back_period: 0s
 
table_manager:
  retention_deletes_enabled: false
  retention_period: 180h

2. 启动

Githup loki

3. 性能和原理

1). 组件介绍

参考一

• Loki实现由众多的组件组成, 每个组件都会拉起一个gRPC的服务来实现内部互通, 同时也对外暴露了一个HTTP/1的服务用来提供外部服务以应答API请求. 不同的组件会根据角色的差异提供不同的API, 目前loki主要由以下几个组件构成
  • Distributor
    • 主要负责分发从客户端上报的日志, 在进行完日志的校验之后便会分发给ingester处理. Distributor使用了一致性哈希以及一个可以配置的副本数来决定不同的日志流的后端ingester. 哈希环信息的存储使用了Consul. Ingester会根据自身的状态注册在哈希环上来标识自身可提供服务的状态. Distributor会使用注册租户id和标签集时作为哈希的输入, 计算出对应的哈希环位置, 并找到对应的ingester
  • Ingester
    • Ingester是loki中比较核心的服务, 该服务将从Distributor发送来的日志进行转储到后端存储, 并给Querier提供仍在内存中未写盘的数据查询功能. Ingester注册在哈希环上的状态有PENDING, JOINING, ACTIVE, LEAVING, UNHEALTHY, 除了ACTIVE状态外, 其余状态都只会提供部分服务 在存储到真正的存储前, 日志流只有按顺序收到才会被处理, Ingester会按照标签的组合set构建若干压缩过的chunks, 间隔一段时间将chunks作为整体刷写到后端存储. 刷进后端存储的chunks被标记为只读
  • Query frontend(Optional)
    • Querier frontend 的部署可以为查询提供加速, 他提供了排队, 切分大请求, 缓存等机制
  • Querier
    • Querier则是用来提供查询服务, 他使用了LogQL, 一种类似于PromQL的语言作为用户界面. Querier会查询已经写入后端存储的chunks以及仍在ingester内存中的数据, 根据label查找数据后, 再遍历数据查找到满足条件的日志
  • Chunk Store
    • Chunk Store是Loki的后端存储框架, 可以支持多种存储方式, 存储分为两部分:索引的存储和真正的日志数据存储
    • 索引存储目前可以使用 Amazon DynamoDB, Google Bigtable, Apsache Cassandra服务提供 日志存储使用了KV存储,目前可以使用Amazon DynamoDB, Google Bigtable, Apsache Cassandra, Amazon S3, Google Cloud Store来实现

2). 特点

参考一

• loki 和 ES 最大的不同是 loki 只对标签进行索引而不对内容索引， ES 无论你查不查，巨大的索引开销必须时刻承担
• loki 只对标签进行索引，那么性能上就有局限，为了弥补没有全文索引带来的查询降速使用，Loki 将把查询分解成较小的分片，可以理解为并发的grep，同时支持 index、chunk 和 result缓存提速
• Loki使用的是自己的查询语言LokiQL，这需要一定的学习曲线

4. 集群

• loki核心服务distributor、ingester、querier没有分离，而是启动在一个实例当中
• 抛弃了consul和etcd外部的kv存储，而是直接用 memberlist 在内存中维护集群状态，Loki的memberlist使用的是 gossip协议来让集群内的所有节点达到最终一致性的
• 使用boltdb-shipper替代其他日志索引方案

Loki2.0版本之后，对于使用boltdb存储索引部分做了较大的重构，采用新的boltdb-shipper模式，可以让Loki的索引存储在S3上，而彻底摆脱Cassandra或者谷歌的BigTable。此后服务的横向扩展将变得更加容易。关于bolt-shipper的更多细节，可以参考：https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/

二、prometail

• prometail是一个跟踪日志文件并将其推送给 Loki 的代理

server:
  http_listen_port: 9080
  grpc_listen_port: 0
  grpc_server_max_recv_msg_size: 15728640
  grpc_server_max_send_msg_size: 15728640

positions:
  filename: /opt/loki/promtail/positions.yaml

clients:
  - url: http://192.168.66.178:3100/loki/api/v1/push

scrape_configs:
- job_name: app_log
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs_178
      __path__: /var/log/*log
      #__path__: /ceph_root/{dev,test}/apps_data/*/log/*log