上海短期网站建设培训,我的wordpress不显示图片,外包app开发多少钱,营口市城乡住房建设局网站一、loki
Github
ELK虽然功能丰富#xff0c;但规模复杂#xff0c;资源占用高#xff0c;操作苦难#xff0c;很多功能往往用不上#xff0c;loki 受 prometheus 启发的水平可扩展、高可用、多租户日志聚合系统#xff0c;它的设计非常经济高效且易于操作#xff0c;…
一、loki
Github
ELK虽然功能丰富但规模复杂资源占用高操作苦难很多功能往往用不上loki 受 prometheus 启发的水平可扩展、高可用、多租户日志聚合系统它的设计非常经济高效且易于操作不对日志进行全文索引。而是为每个日志流建立一组标签并通过存储压缩非结构化日志和索引元数据特别适合存储 Kubernetes Pod 日志。Pod 标签等元数据会自动抓取并建立索引
1. 配置文件
参考一
配置文件说明
auth_enabled: false # 通过 X-Scope-OrgID 标头启用身份验证如果为 true则必须存在。 如果为 false则 OrgID 将始终设置为“ fake”默认值trueserver: # 用于配置 loki 提供 http 和 gRPC 这两种服务的行为http_listen_port: 3100 # Loki http 监听端口号为3100grpc_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/chunksrules_directory: /tmp/loki/rulesreplication_factor: 1ring:kvstore:store: inmemoryquery_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-activecache_location: /tmp/loki/boltdb-shipper-cache # 配置BoltDB缓存文件的存储目录为/tmp/loki/boltdb-shipper-cachecache_ttl: 24 # 配置BoltDB缓存的TTLshared_store: s3 # 使用 s3 作为数据存储aws:s3: s3://admin:minio0304minio.yeemiao.net.cn/buckets/lokis3forcepathstyle: trueschema_config:configs:- from: 2020-10-24store: boltdb-shipperobject_store: filesystemschema: v11index:prefix: index_period: 24hruler:alertmanager_url: http://localhost:9093 # Alertmanager的URLtable_manager: # 日志保存时长retention_deletes_enabled: trueretention_period: 24h # 必须是24小时的倍数案例配置文件 auth_enabled: falseserver:http_listen_port: 3100 #如是云服务需打开3100端口grpc_listen_port: 9096grpc_server_max_recv_msg_size: 8388608grpc_server_max_send_msg_size: 8388608ingester:lifecycler:address: 0.0.0.0 #监听地址,可不做修改。ring:kvstore:store: inmemoryreplication_factor: 1final_sleep: 0schunk_idle_period: 5mchunk_retain_period: 30smax_transfer_retries: 0ingester_client:remote_timeout: 2mschema_config:configs:- from: 2023-01-29store: boltdbobject_store: filesystemschema: v11index:prefix: index_period: 168hstorage_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: 100MiBlimits_config:enforce_metric_name: falsereject_old_samples: truereject_old_samples_max_age: 168h#ngestion_rate_strategy: localingestion_rate_mb: 30ingestion_burst_size_mb: 60per_stream_rate_limit: 10MBper_stream_rate_limit_burst: 20MBmax_query_length: 0hchunk_store_config:max_look_back_period: 0stable_manager:retention_deletes_enabled: falseretention_period: 180h2. 启动
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: 9080grpc_listen_port: 0grpc_server_max_recv_msg_size: 15728640grpc_server_max_send_msg_size: 15728640positions:filename: /opt/loki/promtail/positions.yamlclients:- url: http://192.168.66.178:3100/loki/api/v1/pushscrape_configs:
- job_name: app_logstatic_configs:- targets:- localhostlabels:job: varlogs_178__path__: /var/log/*log#__path__: /ceph_root/{dev,test}/apps_data/*/log/*log
