业务中使用的日志架构是基于Loki来搭建的，最近发现了一个很诡异的问题，有些log的label与label之间对应不上，经过一番尝试后虽然解决了问题，但不知道原由。

grafana出品的loki日志框架完美地与kubernetes的label理念结合，相对于EFK来说更加轻量级，非常适合不需要日志聚合的场景.目前新上集群考虑都彩loki做为基础工具, 直接在grafana中展示

在这里记录下使用Loki踩过的坑, 不定期更新

Mpi: Message Passing Interface，消息传递接口

由于AI业务中使用到了MPI, 网上看MPI教程写的也是云里雾里，很难理解清楚，作者这里结合自身负责的业务来理解MPI的实现方式.

如果有理解存在有遗留或者错误的地方，请各位过客不吝赐教.

flannel在kubernetes中算是比较常用的cni, 其中vxlan又是flannel中常用的模式,最近又详细地看了一遍vxlan的实现方式, 每看一次都会发现新大陆，听的太多人说flannel的vxlan需要封包解包，但并不是所有的人都知道到底是把什么封到包里，包指的又是什么？

今天在排查集群一个问题时，发现相关的pod的状态为UnexpectedAdmissionError,在这之前从未没遇到过pod还有这种状态的，一脸好奇，在解决问题的过程中，发现越挖越深, 里面涉及到的信息也是相当的多，特此记录一下.

历史文章:

可观测性到底在说什么

opentelemetry架构及名词介绍

全链路追踪的TraceID与SpanID

整个opentelemetry体系还是相当复杂的，这里没办法将所有opentelemetry的东西讲清楚，直接通过case顺带opentelemetry里的概念来拆解会比较直观

这里通过一个简单的golang demo来介绍怎么接入opentelemetry以实现Metrics跟Trace的传递

历史文章:

可观测性到底在说什么

opentelemetry架构及名词介绍

在opentelemetry架构及名词介绍 中就引出了一个问题: 无论在数据平面如何做流量劫持，如何透传信息，以及如何生成或者继承Span，入口流量和出口流量之间的链路都存在无法串联的问题， 这个问题要解决还是需服务来埋点透传，将链路信息透传到下一次请求当中去

历史文章:

可观测性到底在说什么

上文简单说了下可观测性，然后引出了主角: opentelemetry

可观测性一个很重要的领域Trace有两个业界标杆: 一个是OpenTracing，另一个OpenCensus，OpenTracing其实是一个规范，jeager就是基于opentracing实现的开源工具，而OpenCensus则是由google开源的度量工具，简单来说，这两者在可观测性领域功能高度重合，因此，在CNCF主导下进行了合并形成opentelemetry项目，OpenTracing跟penCensus共同推进opentelemetry，两者的官网也赫赫表达基本不再维护，同时opentelemetry也致力于trace、logging、metrics间的关联性.

可观测性(Observability)并不是一个新词，而在几十年前被广泛地用于控制理论，用它来描述和理解⾃我调节系统。随着容器技术、微服务、⽆服务器迅速流行，使得系统间的访问越来越复杂，在云上、本地或两者上可能会运⾏数千个进程， 使用传统的监控技术和⼯具很难跟踪这些分布式架构中的通信路径和相互依赖关系。系统内部的可见性就变得非常重要。

那可观测性到底在说什么呢?

使用kubernetes遇到最多的70%问题都可以归于网络问题，最近发现如果内核参数: bridge-nf-call-iptables设置不当的话会影响kubernetes中Node节点上的Pod通过ClusterIP去访问同Node上的其它pod时会有超时现象，复盘记录一下排查的前因后因.