前几天茶水间里突然有同事抛出一个话题，说是现在的日志系统越搞越复杂，又是ELK，又是Redis，甚至还要扯上对象存储，这会不会属于典型的“过度设计”？他反问了一句：“直接存关系数据库不香吗？”

这一问，倒是勾起了我不少回忆。说实话，关于日志模块的设计，无论项目体量大小，这dou不是一个Ke以随便应付的边缘功Neng。它就像是飞机上的黑匣子，平时不显山不露水，甚至可Neng被你遗忘在角落里吃灰。但一旦系统出了大问题，想要在茫茫数据海中捞针，定位那个导致崩溃的罪魁祸首时一套严谨、可靠且高效的日志设计，就是你Zui后的救命稻草。它Neng让你在冷汗直流的运维事故中，迅速找到破局的关键，避免事态进一步恶化。

为什么我坚决反对把日志塞进关系型数据库？

在聊怎么构建之前，我们得先达成一个共识：为什么不Neng用MySQL或者SQL Server这类关系型数据库来存日志？

从性Neng角度来kan，Web系统的日志产生速度是非常密集的，尤其是在高并发场景下。频繁地对数据库进行写入操作，会严重占用IO资源，这简直就是拿业务系统的稳定性开玩笑。你可Neng会说：“我把业务库和日志库分开不行吗？”当然行，但即便分开了关系型数据库的数据增长速度也是个大问题。表数据量一旦上去，查询速度就会呈指数级下降。而且，日志分析往往需要模糊查询、全文检索，这恰恰是关系型数据库Zui不擅长的领域，却是ElasticSearch这类文档型数据库的强项。

也是geng重要的一点，就是内部安全审计。是绝对无法接受的。而ES这类NoSQL方案，配合适当的权限控制，安全性要高得多。

架构设计：ELK + Redis 的黄金搭档

既然排除了关系型数据库，那我们的目光自然就转向了业界成熟的ELK技术栈。不过在实际落地中，我引入了Redis作为缓冲层。这并非多此一举，而是为了解耦。

我的架构图大概是这样的：应用层产生的日志， 通过Serilog组件进行标准化处理，然后推送到Redis的队列中。Redis在这里充当了一个“蓄水池”的角色，不管后端的Logstash处理得快还是慢，它douNeng先稳稳地接住日志洪峰，不会阻塞业务线程。随后Logstash作为数据传输管道，从Redis中慢慢“喝”取数据，经过清洗、解析后Zui终存入ElasticSearch，并由Kibana进行可视化展示。

Redis：不仅仅是缓存

有人可Neng会问，为什么不直接写ES？直接写当然Ke以但在日志量激增的时候，ES的写入压力会非常大。引入Redis队列，Ke以实现生产者和消费者的速率匹配。而且，Redis的List结构天然就是一个高性Neng的消息队列，用来存临时的日志消息再合适不过了。

基础设施搭建：ElasticSearch 的那些坑

说完了架构，我们得动手干脏活累活了。ElasticSearch是基于Java开发的，这也就意味着它对运行环境有诸多挑剔。Ru果你直接用root用户启动，它大概率会给你甩脸色kan。

我们需要创建一个专门的用户，比如叫`elsearch`。这一步千万别偷懒，安全规范总是用血泪教训换来的。

groupadd elsearch
useradd -m -g elsearch elsearch
passwd elsearch # 输入密码
chown -R elsearch:elsearch /opt/es/elasticsearch/
chown -R elsearch:elsearch /usr/local/elasticsearch/data/
chown -R elsearch:elsearch /usr/local/elasticsearch/logs/

除了用户权限，系统参数也是个雷区。你可Neng会遇到类似“max number of threads for user is too low”或者“max virtual memory areas vm.max_map_count is too low”的错误。这时候就得乖乖地去修改`/etc/security/limits.conf`，把文件句柄数和线程数调大，或者修改`sysctl.conf`调整虚拟内存设置。

配置文件 elasticsearch.yml 的精髓

ES的配置文件里有几个关键点值得玩味。比如集群名称，同一个集群内的节点必须保持一致，否则它们就是“路人”。节点名称则要区分开。

关于网络配置，默认它只监听本地回环地址，你得把它改成`0.0.0.0`或者具体的IP，否则别人连不上你。端口嘛，9200是HTTP通信端口，9300是节点间通信端口，建议别改，辨识度高，运维人员一kan9200就知道是ES在跑。

cluster.name: magicloud-cluster
node.name: es-node1
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: 
cluster.initial_master_nodes: 
action.destructive_requires_name: true

这里有个小细节，为了防止手滑删库跑路，建议开启`action.destructive_requires_name: true`，这样删除索引时必须显式指定名称，禁止通配符删除。

数据管道：Logstash 的配置艺术

ES搭好了接下来就是Logstash。这家伙就是个搬运工，负责把Redis里的数据搬到ES里。它的配置文件主要分为Input、Filter和Output三块。

在Input部分，我们配置Redis的数据源。这里要注意，我们定义了Key，比如`eslog`，数据类型选`list`。

input {
  redis {
    codec => plain
    host => "192.168.1.100"
    port => 6379
    db => 0
    key => "eslog"
    data_type => list
    password => "yourpassword"
  }
}

Filter部分是Logstash的灵魂。这里我们用到了`grok`插件，它Ke以通过正则表达式把那一长串非结构化的日志文本“撕碎”成一个个字段。比如我们Ke以把日志里的时间、IP、请求路径、参数dou提取出来。

filter {
  grok {
    match => {
      "message" => "%{DATA:system} %{DATA:level} %{DATA:time} %{DATA:user} %{DATA:method} %{DATA:path} \"%{DATA:param}\" %{DATA:ip} %{DATA:webbrower} \"%{DATA:remark}\""
    }
    remove_field => 
  }
  geoip {
    source => "ip"
  }
}

顺便提一句，Ru果你的日志里包含身份证号、手机号这种敏感信息，但又不想改代码，完全Ke以在Grok这里配置脱敏规则，或者直接在Output之前把字段替换掉。`geoip`插件也是个好东西，Neng根据IP定位出地理位置，Zuo运维分析时特别直观。

Zui后是Output，直接指向ES集群。

output {
  elasticsearch {
    hosts => 
    index => "cloudlog-%{+YYYY.MM.dd}"
  }
}

应用端实践：Serilog 的优雅集成

基础设施搭好了代码里怎么写？在.NET Core环境下Serilog绝对是个不二之选。它结构化、可 ，而且社区非常活跃。

1. 中间件拦截上下文

日志不仅仅是记录“报错了”，geng重要的是记录“谁在什么时间什么地点干了什么”。所以我们需要一个中间件来拦截HTTP请求，把上下文信息塞进去。

public class LogContextMiddleware
{
    private readonly RequestDelegate _next;
    public LogContextMiddleware
    {
        _next = next;
    }
    public async Task InvokeAsync
    {
        // 这里为了隐私，不直接存用户明文，而是存Token
        string userToken = "Anonymous";
        var tokenItem = context.Request.Headers?.Where.FirstOrDefault;
        if 
        {
            userToken = tokenItem.Value.Value.ToString.Replace;
        }
        string ip = GetIp;
        string path = context.Request.Path;
        string method = context.Request.Method;
        string param = GetRequestParameters;
        string userAgent = context.Request.Headers.FirstOrDefault ?? "Unknown";
        // 利用 LogContext 将这些属性推入日志上下文
        using )
        using )
        using )
        using )
        using )
        using )
        {
            await _next;
        }
    }
}

2. 自定义 Redis Sink

Serilog本身支持hen多Sink，但为了满足我们“先写Redis”的需求，我们需要自定义一个Sink。这里我定义了一个`RedisLogSink`，专门负责把格式化好的日志推送到Redis队列。

public class RedisLogSink : ILogEventSink, IDisposable
{
    private readonly string _systemLabel;
    private readonly IRedisServiceProvider _redisService;
    public RedisLogSink
    {
        _systemLabel = systemLabel;
        _redisService = redisService;
    }
    public void Emit
    {
        if  return;
        // 生产环境通常不需要Debug级别的日志，减少网络传输
        if 
        {
            return;
        }
        // 从上下文中取出我们在中间件存入的信息
        var userToken = GetPropValue;
        var ip = GetPropValue;
        var path = GetPropValue;
        var method = GetPropValue;
        var param = GetPropValue;
        var UserAgent = GetPropValue;
        var message = logEvent.RenderMessage;
        // 拼接成Zui终字符串，格式要和Logstash里的Grok对应上
        var msg = $"{_systemLabel} {logEvent.Level} {DateTime.Now:HH:mm:ss} {userToken} {method} {path} \"{param}\" {ip} {UserAgent} \"{message}\"";
        // 异步推送到Redis
        _redisService.LPushAsync;
    }
    public void Dispose { }
}

3. 条件写入与注册

为了方便开发调试，我们在本地开发时可Neng希望日志直接写文件，而不是推到Redis。这时候Ke以用`ConditionalLogSink`Zuo个判断。

public class ConditionalLogSink : ILogEventSink
{
    private readonly ILogEventSink _sink;
    public ConditionalLogSink
    {
        if 
        {
            _sink = new LevelBasedFileSink;
        }
        else
        {
            _sink = new RedisLogSink;
        }
    }
    public void Emit
    {
        _sink.Emit;
    }
}

Zui后在`Program.cs`里注册一下这套系统就算跑通了。

Log.Logger = new LoggerConfiguration
    .MinimumLevel.Debug
    .Enrich.FromLogContext
    .WriteTo.Conditional(
        c => isDev,
        wt => wt.Console
    )
    .WriteTo.Sink)
    .CreateLogger;
builder.Logging.ClearProviders;
builder.Logging.AddSerilog;

可视化与善后：Kibana 与 归档

数据有了怎么kan？这就轮到Kibana出场了。Kibana的配置相对简单，主要就是指定ES的地址。记得把语言改成中文，不然kan着那一堆英文报表容易头晕。

server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: 
i18n.locale: "zh-CN"

启动Kibana后你就Ke以在浏览器里通过索引模式查kan日志了。那种感觉，就像是从听诊器变成了核磁共振，系统内部的一切dou纤毫毕现。

Zui后还得提一句日志的“善后”工作。ES虽然强大，但存储成本也不低。对于短期的热数据，比如Zui近7天的，放ES里没问题。但Ru果是几个月甚至几年前的冷数据，还放在ES里那就是浪费资源。这时候，应该利用ES的ILM策略，把老数据归档到对象存储上，或者直接删除。这又是另一个宏大的话题了这里就不展开细说了。

构建一套高效的日志模块，从来dou不是一蹴而就的事情。它需要你对业务有理解，对技术栈有掌控，甚至还需要一点对系统稳定性的敬畏之心。虽然引入ELK和Redis增加了系统的复杂度，但相比于生产环境故障时那种两眼一抹黑的绝望，这点投入绝对是物超所值的。希望这篇碎碎念Neng给你在日志系统设计上带来一点点启发，周末愉快！

---