点击图片直接进入网站怎么做别墅装修公司排名前十强

点击图片直接进入网站怎么做,别墅装修公司排名前十强,宝安中心网站建设,最近的广告公司目前为止#xff0c;我查询服务器日志的方式都是小作坊式做法#xff0c;先是连进服务器找到日志文件#xff0c;要么使用 vim 打开文件搜索要么就是用 grep。当前我只有一个服务器进程#xff0c;操作起来还好#xff0c;但是如果需要增加服务器进程数量进行负载均衡的话…目前为止我查询服务器日志的方式都是小作坊式做法先是连进服务器找到日志文件要么使用 vim 打开文件搜索要么就是用 grep。当前我只有一个服务器进程操作起来还好但是如果需要增加服务器进程数量进行负载均衡的话就非常麻烦急需一个日志采集系统在统一的地方集中管理和查找日志。恰好公司最近将日志采集从 elk 切换到了 victoria-logs我也稍微有些好奇当前的日志生态大致是怎样的。victoria-logs事实上提到日志采集系统或者说框架我第一个想到的就是 elk也是目前这个领域应用最为广泛的elastic 负责数据存储和搜索logstash 负责日志数据采集kibana 负责图形化展示。之前使用的时候觉得真是超级好用然而缺点就是太重了这方面是我无法接受的还记得前段时间研究搜索引擎时刚用 docker 启动 elastic search 就占用了 1GB 内存直接惊掉下巴这根本不是我租的那个蝇量级服务器能够承担的。用不了 elk 只能退而求其次首先分析一下我的需求其实就是需要一个集中统一管理日志的地方方便查日志如此一来 kibana 所代表的角色就可有可无了或者用服务器目前已经部署的 grafana 代替。日志数据采集是必须的总要有一个搬运工将程序日志收集到数据库中但并不复杂毕竟我的服务器程序非常简单打印的日志也都是固定格式开发个日志采集也不怎么费事。那么重担就落在寻找 elastic 的替代品身上了。在一番搜索过后摘选出了两个比较信得过的技术栈 victoria-logs 和 lokivictoria-logs 是因为公司项目本身就在用借机熟悉一下不是坏事loki 则是有 grafana 背书我还是比较信任 grafana 的。docker run -d \--nameloki \--network monitoring \-p 3100:3100 \grafana/loki:latest \-config.file/etc/loki/local-config.yamldocker run -d \--name victoria-logs \--network monitoring \-p 9428:9428 \-v /srv/data/victoria-logs:/victoria-logs-data \victoriametrics/victoria-logs:latest \-storageDataPath/victoria-logs-data \-retentionPeriod30ddocker statsCONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDSb9635e741ba7 victoria-logs 0.05% 5.469MiB / 7.654GiB 0.07% 872B / 126B 0B / 0B 9af17f30b01a4 loki 1.38% 61.79MiB / 7.654GiB 0.79% 1.3kB / 126B 0B / 0B 13稍微对比了下 docker 镜像启动后空档运行的资源占用看来是 victoria-logs 小胜一筹。就没对比满负荷的资源占用了毕竟现在网站日访问量都不知道能不能到三位数很难说会有服务器满载的情况总之降本增效不一定增效但一定降本了~在 VictoriaLogs 文档 中也介绍了 victoria-logs 自身的一些优点和特色还有一些从 elastic 和 loki 迁移过来的用户的分享虽然 Github VictoriaMetrics/VictoriaLogs 的 Star 数量仅有几百个有点惨不忍睹。不过我这个也不是企业级项目够用就行如果后面业务量增加的话再切换成 elk。vector日志采集的技术方案选择相对就很随意了选择了比较流行的 vector同样使用 docker 部署需要注意其中两个地方需要容器挂载一个是宿主机的日志目录对应的是服务器程序输出文件的位置一个是配置文件。docker run -d \--name vector \--network monitoring \-v /etc/vector/vector.yaml:/etc/vector/vector.yaml:ro \-v /var/log/blog:/var/log/blog:ro \timberio/vector:nightly-alpine \--config /etc/vector/vector.yaml配置文件可以用 toml 也可以用 yaml或者是 json本来我问 ChatGPT 给出的示例都是 toml 的也打算用 toml但是后面看文档中大部分示例都是用的 yaml本着方便 copy 的原则我这里也选用了 yaml 格式的配置虽然实际上都差不多。文档参考Vector quickstart。vim /etc/vector/vector.yaml配置整体分三块而且是非常标准的上中下第一块 sources 是数据输入比如我的需求是监听文件更新所以类型选择 type。第二块 transforms 是数据处理比如做一些简单的转换。第三块 sinks 是数据输出这里我需要把处理好的数据发送到 victoria-logs 中去。方便的是 victoria-logs 本身就兼容 elasticsearch 的 api已有的技术栈可以无痛迁移具体参考VictoriaLogs / Data Ingestion / Vector Setup。sources:blog_server_logs:type: fileinclude:- /var/log/blog/*.logread_from: beginningtransforms:blog_server_json_logs:type: remapinputs:- blog_server_logssource: |._msg .message.message parse_json(.message) ?? {}.level .message.level.timestamp .message.tssinks:victorialogs:inputs:- blog_server_json_logstype: elasticsearchendpoints:- http://victoria-logs:9428/insert/elasticsearch/compression: gziphealthcheck:enabled: falsequery:_msg_field: message_time_field: timestamp_stream_fields: host,container_namevector 打印采集到的数据遇到服务一部署就行正常运行如果不是经验丰富那一定是幸运女神的眷顾。而我这次就没这么幸运了那边服务器日志正常增加这边 victoria-logs 却是什么数据都没有查看 vector 的日志只有监听文件成功的日志打印看起来一切正常真让人摸不着头脑。2025-09-28T14:59:15.296799Z INFO source{component_kindsource component_idblog_server_logs component_typefile}:file_server: vector::internal_events::file::source: Found new file to watch. file/var/log/blog/blog_backend.log所幸 vector 还提供了更多的输出方式比如打印日志将配置表添加如下字段类型选择 console。sinks:print:inputs:- blog_server_logstype: consoleencoding:codec: json如果成功就会在 vector 的日志中看到打印的内容docker logs vector --tail 50可惜的是我依旧没有看到打印悬着的心终于死了。经过一番摸索终于拨开云雾见天明发现是在多次重试的过程中删除过日志文件但是 vector 保存了上次收集日志的位置可能是防止重启或者什么特殊情况导致重复消费。而我在调试的过程中有过重启服务器和删除日志的操作但是 vector 检查点不重置新生成的日志小于检查点的位置vector 会认为所有日志都消费过了直到新日志超过检查点。解决办法就是删除镜像重新运行 vector或者更换一下日志文件的位置。zap 日志输出格式最初的最初我的想法是只要收集到日志就好了不做处理直接存起来后面查但事与愿违一下就遇到了拦路虎 victoria-logs 解析 json 失败报错信息如下。2025-09-28T07:38:48.422Z warn VictoriaLogs/app/vlinsert/jsonline/jsonline.go:54 remoteAddr: 172.18.0.6:50528; requestURI: /insert/jsonline; cannot process jsonline request; error: unexpected tail: T15:38:4608:00 \x1b[34mINFO\x1b[0m Vodka inte...\: 200, \body_size\: 2658, \latency\: 4}; line contents: 2025-09-28T15:38:4608:00 \x1b[34mINFO\x1b[0m Vodka internal Request {\method\: \GET\, \path\: \/metrics\, \client_ip\: \172.18.0.2\, \proto\: \HTTP/1.1\, \status\: 200, \body_size\: 2658, \latency\: 4}这要追溯到 golang 的 zap 日志打印库我的设置是打印 level 时前后加上固定的转义字符比如 \x1b[34mINFO\x1b[0m让 INFO 或者 ERROR 在控制台中显示蓝色和红色然而这个转义字符给 json 解析造成了很大麻烦。解决方法之一是在 vector 的数据处理部分添加大量逻辑替换或者复杂正则匹配方法二则是更改服务器日志打印参数开发环境便于肉眼观察可以打印颜色但是生产环境就要规规矩矩只输出常规字符。这里我参考了Get started with ECS Logging Go (Zap)。// 带有转义色彩控制字符config : zapcore.EncoderConfig{EncodeLevel: zapcore.CapitalColorLevelEncoder,// ...}// 以便于查日志的控制台格式输出encoder zapcore.NewConsoleEncoder(encoderConfig)// 不带转义色彩控制字符config : zapcore.EncoderConfig{EncodeLevel: zapcore.LowercaseLevelEncoder,// ...}// 以 json 的格式输出encoder zapcore.NewJSONEncoder(encoderConfig)原本的格式2025-10-01T00:43:5608:00 ^[[31mERROR^[[0m serv.go:86 failed to initialize database, got error Error 1045 (28000): Access denied for user nobodylocalhost (using password: YES)更改后的格式{level:error,ts:1759252206.642765,caller:serv.go:86,msg:failed to initialize database, got error Error 1045 (28000): Access denied for user nobodylocalhost (using password: YES)}最好还是采用 zap 官方设置比如 NewDevelopmentConfig 和 NewProductionConfig如果需要的话再在这个基础上修改某些字段的值。vector remap language好了现在日志输出非常规范了vector 直接可以解析但是仍需要一些处理把 json 文本解析成字段方便后面 victoria-logs 统计和显示如果是自定义格式的日志就要使用正则匹配这时候就需要 vrl 了可以查看官方文档Vector Remap Language (VRL)其中有一些范例可以参考。docker logs vector --tail 50使用 zap 打印日志比如fields : []zap.Field{zap.String(method, c.Request.Method),zap.String(path, c.Request.URL.Path),zap.String(client_ip, c.ClientIP()),zap.String(proto, c.Request.Proto),}logger.Error(Vodka Internal Server Error, fields...)输出的日志格式是{level:info,ts:1759286696.6425128,msg:Vodka internal Request,method:GET,path:/metrics,client_ip:172.18.0.2,proto:HTTP/1.1,status:200,body_size:2544,latency:2}编写如下 vrltransforms:blog_server_json_logs:type: remapinputs:- blog_server_logssource: |._msg .message.message parse_json(.message) ?? {}.level .message.level得到的 vector 处理后的数据{_msg:{\level\:\info\,\ts\:1759288966.6411865,\msg\:\Vodka internal Request\,\method\:\GET\,\path\:\/metrics\,\client_ip\:\172.18.0.2\,\proto\:\HTTP/1.1\,\status\:200,\body_size\:2264,\latency\:1},file:/var/log/blog/blog_backend.log,host:f33342bfbf69,level:info,message:{body_size:2264,client_ip:172.18.0.2,latency:1,level:info,method:GET,msg:Vodka internal Request,path:/metrics,proto:HTTP/1.1,status:200,ts:1759288966.6411865},source_type:file,timestamp:2025-10-01T03:22:47.353385037Z}victoria-logs 和 grafanavictoria-logs 本身有一个网页的界面视觉上蛮舒服的。20251001-233219grafana 没有内置 victoria-logs需要额外下载插件然后添加 datasource不需要太多配置只需设置下 victoria-logs 的地址效果如下。20251001-225851ElasticLogstashKibana 技术栈可以简称成 ELK那么 VictoriaLogsVectorGrafana 可不可以称作 VVG不过听起来却是没有 ELK 好听。