prometheus|云原生|轻型日志收集系统loki+promtail的部署说明

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
可观测可视化 Grafana 版,10个用户账号 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: prometheus|云原生|轻型日志收集系统loki+promtail的部署说明

一,

日志聚合的概念说明

  • 日志------

每一个程序,服务都应该有保留日志,日志的作用第一是记录程序运行的情况,在出错的时候能够记录错误情况,简单来说就是审计工作,例如nginx服务的日志,kubernetes集群的pod运行日志,Linux系统的系统日志。

其次是数据库的日志,记录数据库的运行细节,在需要的时候通过日志回溯数据库动作,比如MySQL数据库的binlog日志,这类日志比较特殊,基本没有聚合的意义。

  • 日志聚合----

指的是将分散在各个服务器上的日志统一一个入口程序来查看其内容,并可通过关键字或者正则表达式搜索特定的管理人员感兴趣的内容,例如,efk日志系统,elastisearch负责将分散的日志收集,flueed将es收集的日志进行预处理以符合我们的审计工作需求,最终通过kibana这个web界面查看这些分散于各个服务器的日志,以提高管理服务器的效率,毕竟,日志没有聚合的时候,我们是需要每个服务器都登陆,然后找到相应的日志文件,打开日志文件,检索需要的内容这样一个复杂的流程,而聚合日志后,通过特定标签就可以查询检索到我们需要的信息了。

那么,现在的常用日志聚合系统有elk,efk,毫无疑问的,这些系统是比较重的,复杂的(架构复杂,所以维护管理也复杂,在系统出现问题的时候会比较难以判断,解决),而这些无疑是会提高我们的使用门槛的,毕竟,如果是在生产上,我们可能希望这个日志系统是稳定高效的,那么,es可能就需要以集群的架构来部署,f或者l可能也需要集群的架构,而集群的维护和管理工作这些都限制了我们使用的欲望。

OK,有没有一个相对elk这样的日志系统更为简单的,查询效率更高的日志系统呢?答案当然是   ---必须有,loki+promtail+grafana基本可以满足中小企业的日志聚合功能。

那么,本文将就loki+promtail+grafana这个日志聚合系统的部署和简单使用做一个尽量详尽的介绍。

二,

架构说明

日志收集器---promtail ,负责将需要聚合的日志发送到loki,通常每个日志节点都需要安装

日志处理器---loki,负责将promtail推送过来的日志打上特定标签,管理这些聚合到的日志,应用层的服务,带有api,通常只安装这么一个服务

日志展示部分---grafana,展示数据,也就是web端展示,日志的内容统一暴露接口,通常只安装这么一个服务

本文使用的是centos7操作系统

三,

部署方式

部署方式非常多,helm,kubernetes内集成yaml清单形式,二进制,rpm安装包形式,docker容器形式都可以,本文主要是二进制的方式安装

二进制方式安装部署的优点是部署简单,方便,形式灵活,可深度定制

四,

二进制安装包的获取

百度网盘下载地址:链接:https://pan.baidu.com/s/1XKqwdJrrYYewsAcy8foQ5Q?pwd=kkey
提取码:kkey

或者在github官网下载,地址为:

Releases · grafana/loki · GitHub

五,

loki的部署

相关介质上传到服务器上后,解压,编写配置文件,文件内容如下:

cat >loki-cfg.yaml<<EOF
auth_enabled: false
server:
  http_listen_port: 13100   #http监听端口,代理服务(promtail)会向此端口发送日志流
  grpc_listen_port: 9086   #grpc监听端口,简单部署不用管
ingester:
  lifecycler:
    address: 192.168.123.11
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
    final_sleep: 0s
  chunk_idle_period: 5m
  chunk_retain_period: 30s
  max_transfer_retries: 0
schema_config:
  configs:
    - from: 2023-12-02 #2023-12-02之后loki信息用下面的配置,这个主要是用来做兼容的
      store: boltdb  #索引使用哪种存储
      object_store: filesystem  #怎么存储,简单部署的话保存在本地文件系统
      schema: v11
      index:
        prefix: index_
        period: 24h #索引期限24小时
storage_config:
  boltdb:
    directory: /tmp/loki/index
  filesystem:
    directory: /tmp/loki/chunks
limits_config:
  enforce_metric_name: false
  reject_old_samples: true
  reject_old_samples_max_age: 168h
  ingestion_rate_mb: 32  #采集速率
  ingestion_burst_size_mb: 64 #单次采集大小
  max_entries_limit_per_query: 0  #查询返回的条目的最大行数,默认是5000,0表示无限制
  retention_period: 24h #全局保留期,超过这个时间的日志会被删除,具体删除规则在compactor里配置
  #retention_stream: #局部保留期
  #- selector: '{level="error"}'
  #  priority: 1
  #  period: 720h
chunk_store_config:
  max_look_back_period: 0s #最大日志可见时间,0表示一直可见。or  24h等等
table_manager:
  retention_deletes_enabled: false
  retention_period: 0s
compactor: 
  working_directory: /data/loki/compactor #compactor运行状态保存目录
  shared_store: filesystem
  retention_enabled: true #启动日志删除
  compaction_interval:  10m #compactor每隔10分钟运行一次
  retention_delete_delay: 2h  #在compactor运行2小时后删除
  retention_delete_worker_count: 150 #用150个worker删除chunks
analytics:
  reporting_enabled: false #关闭向loki团队发送此配置文件
EOF

配置文件说明:

 ingestion_rate_mb: 32  #采集速率,如果日志量比较大的话,需要调整的
 ingestion_burst_size_mb: 64 #单次采集大小,如果日志量比较大的话,需要调整的
 max_entries_limit_per_query: 0  #查询返回的条目的最大行数,默认是5000,0表示无限制

这三个是比较重要的,其它的其实是可以默认的,就性能比较好

在Loki中,对于客户端push到distributor中产生的每条日志流是可以对其做条目的大小限制的,这个在配置里面默认是不限制,也就是说每行的日志大小可以是无限?,当然大部分情况下我们都不会去限制这个,如果有的同学环境特殊,可以考虑开启对每行日志的大小限制。

limits_config:
# 日志条目的大小限制,默认不限制
  max_line_size:  | default = none

除此之外,对于单次查询的限制还有的chunk、stream和series的,不过大部分场景我们不会去对此做调整

limits_config:
  # 单个查询最多匹配的chunk个数
  max_chunks_per_query: | default = 2000000
  # 限制查询是匹配到的chunk大小,默认0为不限制
  max_query_length:  | default = 0
  # 单词查询最多匹配到的日志流个数
  max_streams_matchers_per_query: | default = 1000
  # 限制查询时最大的日志度量个数
  max_query_series: | default = 500
  # 查询的并发数
  max_query_parallelism  | default = 14
  # 允许租户缓存结果的有效时间
  max_cache_freshness_per_query   |default = 1m.

启动脚本:

/var/log/loki/ 目录需要提前建立,/opt/loki/loki-linux-amd64 是loki的执行程序,/opt/loki/loki-cfg.yaml是loki的配置文件绝对路径

cat >/etc/systemd/system/loki.service <<EOF
[Unit]
Description=loki
After=network.target
[Service]
ExecStart=/opt/loki/loki-linux-amd64 -config.file=/opt/loki/loki-cfg.yaml &>> /var/log/loki/loki.log
ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TimeoutStartSec=0
Delegate=yes
KillMode=process
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s
[Install]
WantedBy=multi-user.target
EOF

启停和自动启动:

systemctl enable loki && systemctl start loki && systemctl status loki

六,

promtail的部署

promtail的配置文件:

这个是一个非常简单的静态读取/var/log/目录下的log后缀文件信息,并上传到loki

cat promtail_config.yaml 
server:
  http_listen_port: 9080
  grpc_listen_port: 0
# 记录读取日志的位置信息文件,Promtail重新启动时需要它
positions:
  filename: /tmp/positions.ymal
# Loki的api服务的地址
clients:
  - url: http://192.168.123.11:13100/loki/api/v1/push
scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log

promtail的启动脚本:

cat >/etc/systemd/system/promtail.service <<EOF
[Unit]
Description=promtail
After=network.target
[Service]
ExecStart=/opt/loki/promtail-linux-amd64 -config.file=/opt/loki/promtail_config.yaml &>> /var/log/promtail/promtail.log
ExecReload=/bin/kill -s HUP 
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TimeoutStartSec=0
Delegate=yes
KillMode=process
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s
[Install]
WantedBy=multi-user.target
EOF

七,

grafana部署安装

这个没什么好说的,rpm安装启动服务就可以了

添加数据源

直接explore就可以看到如下了:

点击label browser 可以看到:

多说一句,内存和CPU最好还是给的高一点,一开始我只给的4G loki服务经常卡掉,很难受,给到8G后就流畅很多了。

相关实践学习
通过可观测可视化Grafana版进行数据可视化展示与分析
使用可观测可视化Grafana版进行数据可视化展示与分析。
目录
相关文章
|
5天前
|
Windows Python
如何反向读取Windows系统日志EVTX文件?
以下是如何反向读取Windows系统日志EVTX文件
15 2
|
11天前
|
存储 Linux Docker
centos系统清理docker日志文件
通过以上方法,可以有效清理和管理CentOS系统中的Docker日志文件,防止日志文件占用过多磁盘空间。选择合适的方法取决于具体的应用场景和需求,可以结合手动清理、logrotate和调整日志驱动等多种方式,确保系统的高效运行。
12 2
|
16天前
|
监控 Cloud Native 持续交付
云原生技术深度解析:重塑现代应用开发与部署范式####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在现代软件开发中的重要性。通过剖析容器化、微服务架构、持续集成/持续部署(CI/CD)等关键技术,本文旨在揭示云原生技术如何促进应用的敏捷性、可扩展性和高可用性,进而推动企业数字化转型进程。不同于传统摘要仅概述内容要点,本部分将融入具体案例分析,直观展示云原生技术在实际应用中的显著成效与挑战应对策略,为读者提供更加丰富、立体的理解视角。 ####
|
23天前
|
XML JSON 监控
告别简陋:Java日志系统的最佳实践
【10月更文挑战第19天】 在Java开发中,`System.out.println()` 是最基本的输出方法,但它在实际项目中往往被认为是不专业和不足够的。本文将探讨为什么在现代Java应用中应该避免使用 `System.out.println()`,并介绍几种更先进的日志解决方案。
46 1
|
27天前
|
Kubernetes Cloud Native 持续交付
云原生技术:重塑现代应用开发与部署模式####
本文深入探讨了云原生技术的核心概念、发展历程及其在现代软件开发和部署中的关键作用。通过分析云原生架构的特点,如容器化、微服务、持续集成与持续部署(CI/CD),以及它如何促进应用的可伸缩性、灵活性和效率,本文旨在为读者提供一个关于云原生技术全面而深入的理解。此外,还将探讨实施云原生策略时面临的挑战及应对策略,帮助组织更好地把握数字化转型的机遇。 ####
|
30天前
|
监控 网络协议 安全
Linux系统日志管理
Linux系统日志管理
42 3
|
10天前
|
监控 Cloud Native 微服务
云端漫步:探索云原生应用的构建与部署
【10月更文挑战第32天】在数字时代的浪潮中,云原生技术如同一艘航船,承载着企业的梦想驶向未知的海洋。本文将带你领略云原生应用的魅力,从基础概念到实战操作,我们将一步步揭开云原生的神秘面纱,体验它如何简化开发、加速部署,并提升系统的可扩展性与可靠性。让我们一起启航,探索云原生的世界!
|
11天前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
116 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
1月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
216 3
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1625 14