分类 surveillance system 下的文章

2023-08-25

2023年08月25日
208 阅读
0 评论
0 点赞

2023-08-20

linuxea: openobseve单节点和查询语法 OpenObserve声称可以比Elasticsearch 它⼤约可以节省 140 倍的存储成本，同时由Rust开发的可观测性平台(⽇志、指标、追踪)，它可以进行日志搜索，基于sql查询语句和搜索的日志关键字的上下周围数据，高压缩比的存储，身份验证和多租户，支持S3，miniio的高可用和集群，并且兼容elasticsearch的摄取，搜索，聚合api，计划报警和实时报警等功能。如果只是对日志搜索引擎感兴趣，相比于Elasticsearch的和zincSearch，OpenObserve更轻量，它不依赖于数据索引，数据被压缩后存储或者使用parquet列格式存储到对象存储中，尽管如此，在分区和缓存等技术的加持下，速度也不会太慢，并且在聚合查询数据情况下，OpenObserve的速度要比es快的多。OpenObserve的节点是无状态的，因此在水平扩展中，无需担心数据的复制损坏，他的运维工作和成本比Elasticsearch要低得多。并且OpenObserve内置的图像界面，单节点无需使用其他组件，仅仅OpenObserve就完成了存储和查询。同时OpenObserve作为prometheus的远程存储和查看，但是对于查询语句并非全部支持，因此，我们只进行日志收集的处理，其他不进行测试。单节点sled单节点和本地磁盘单节点使用本地磁盘模式，也是默认的方式，对于简单使用和测试在官方数据中，每天可以处理超过2T的数据我们可以简单的理解为sled是存储的元数据的地方，本地磁盘存储的数据。sled单机和对象存储数据存放在对象存储后，高可用的问题交给了对象存储提供商，并且openobseve使用列式存储的方式，并且进行分区，这样的情况下就规避了一定部分因为对象存储与openobseve之间的网络延迟导致的网络问题etcd和对象存储除此之外，进一步来说，元数据也需要进行有个妥善的地方存储，因此，元数据存储的etcd，meta数据存储在本地或者s3来保证数据的安全性单机安装在k8s的用户可以参考官方的deploy文件, 而使用docker-compose我们需要指定三个环境变量，分别是数据的存储目录，用户名和密码 - ZO_DATA_DIR=/data - ZO_ROOT_USER_EMAIL=root@example.com - ZO_ROOT_USER_PASSWORD=Complexpass#123如下version: "2.2" services: openobserve: container_name: openobserve restart: always image: public.ecr.aws/zinclabs/openobserve:latest ports: - "5080:5080" volumes: - /etc/localtime:/etc/localtime:ro # 时区2 - /data/openobserve:/data environment: - ZO_DATA_DIR=/data - ZO_ROOT_USER_EMAIL=root@example.com - ZO_ROOT_USER_PASSWORD=Complexpass#123 logging: driver: "json-file" options: max-size: "100M" mem_limit: 4096m而后我们直接打开映射的5080端口当前的版本中多语言通过机器翻译，因此并不准确loglog支持curl，filebeat,fluentbit,fluentd, vector等，并且这些提供了一定的示例curlcurl在低版本中，我们需要-d指定文件最快，如果你的版本在7.82，那么可以使用--json指定，参考官方文档1.创建一个linuxea的组，组下创建一个名为0819的分区，在0819中写入'[{"author":"marksugar"}]'[root@Node-172_16_100_151 /data/openObserve]# curl http://172.16.100.151:5080/api/linuxea/0819/_json -i -u 'root@example.com:Complexpass#123' -d '[{"author":"marksugar"}]' HTTP/1.1 200 OK content-length: 65 content-type: application/json vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers date: Sat, 19 Aug 2023 07:43:15 GMT {"code":200,"status":[{"name":"0819","successful":1,"failed":0}]}而后创建一组数据，内容如下cat > linuxea.json << LOF [{ "name": "linuxea", "web": "www.linuxea.com", "time": "2023-08-19", "log": "2023-08-18 09:04:01 Info Super Saiyan , this is a normal phenomenon", "info": "this is test" }] LOF接着也添加到linuxea/0819curl http://172.16.100.151:5080/api/linuxea/0819/_json -i -u 'root@example.com:Complexpass#123' --data-binary "@linuxea.json"如:[root@Node-172_16_100_151 /data/openObserve]# cat > linuxea.json << LOF > [{ > "name": "linuxea", > "web": "www.linuxea.com", > "time": "2023-08-19", > "log": "2023-08-18 09:04:01 Info Super Saiyan , this is a normal phenomenon", > "info": "this is test" > }] > LOF [root@Node-172_16_100_151 /data/openObserve]# curl http://172.16.100.151:5080/api/linuxea/0819/_json -i -u 'root@example.com:Complexpass#123' --data-binary "@linuxea.json" HTTP/1.1 200 OK content-length: 65 content-type: application/json vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers date: Sat, 19 Aug 2023 07:46:37 GMT {"code":200,"status":[{"name":"0819","successful":1,"failed":0}]}3, 在linuxea组下创建一个0820的分区写入不同的数据curl http://172.16.100.151:5080/api/linuxea/0820/_json -i -u 'root@example.com:Complexpass#123' -d '[{"author":"marksugar","name":"www.linuxea.com"}]'如下：[root@Node-172_16_100_151 /data/openObserve]# curl http://172.16.100.151:5080/api/linuxea/0820/_json -i -u 'root@example.com:Complexpass#123' -d '[{"author":"marksugar","name":"www.linuxea.com"}]' HTTP/1.1 200 OK content-length: 65 content-type: application/json vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers date: Sat, 19 Aug 2023 07:47:45 GMT {"code":200,"status":[{"name":"0820","successful":1,"failed":0}]}接着，我们回到界面查看数据的插入情况08190820查询默认情况下，如果将要查询的数据的字段是msg, message, log, logs，可以使用match_all('error')，match_all('error')是说匹配所有的error，但前提是msg, message, log, logs的字段内如果不是msg, message, log, logs的，比如是body，我们可以使用str_match(body, 'error')当然，这也可以使用str_match(log, 'error')来进行查询其他更多用法，参考example-queries我们重组数据进行查询如果此时，以下字段中的log中包含了我们需要的数据，那么我们就可以使用match_allcat > linuxea.json << LOF [{ "name": "linuxea", "web": "www.linuxea.com", "time": "2023-08-19", "log": "2023-08-18 09:04:01 Info Super Saiyan , this is a normal phenomenon linuxea", "info": "this is test", "author":"marksugar", }] LOF比如，我们查询的关键字是linuxea如果我们要查询的字段是marksugar，就不能使用match_all('marksugar')，因为match_all只能在是msg, message, log, logs中默认使用，正确的语法是：str_match(author, 'marksugar')，并且str_match的查询比match_all要快而对于其他的，可以直接使用key:value来, 比如： name='linuxea'对于这条查询，也可以使用sql语句的方式 name='linuxea' 等于 SELECT * FROM "0819" WHERE name='linuxea'参考基于k8s上loggie/vector/openobserve日志收集https://openobserve.ai/docs/example-queries/https://everything.curl.dev/http/post/jsonhttps://openobserve.ai/docs/ingestion/logs/curl/

2023年08月20日
263 阅读
0 评论
0 点赞

2023-08-19

linuxea: 基于k8s上loggie/vector/openobserve日志收集在上次的日志收集组件变化中简单的介绍了新方案，通常要么基于K8s收集容器的标准输出，要么收集文件。我们尝试使用最新的方式进行配置日志收集的组合进行测试，如下：但是，在开始之前，我们需要部署kafka,zookeeper和kowl1.kafka修改kafka的ip地址version: "2" services: zookeeper: container_name: zookeeper image: uhub.service.ucloud.cn/marksugar-k8s/zookeeper:latest container_name: zookeeper restart: always ports: - '2182:2181' environment: - ALLOW_ANONYMOUS_LOGIN=yes logging: driver: "json-file" options: max-size: "100M" mem_limit: 2048m kafka: hostname: 172.16.100.151 image: uhub.service.ucloud.cn/marksugar-k8s/kafka:2.8.1 container_name: kafka user: root restart: always ports: - '9092:9092' volumes: - "/data/log/kafka:/bitnami/kafka" # chmod 777 -R /data/kafka environment: - KAFKA_BROKER_ID=1 - KAFKA_LISTENERS=PLAINTEXT://:9092 - KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://172.16.100.151:9092 - KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 - ALLOW_PLAINTEXT_LISTENER=yes depends_on: - zookeeper logging: driver: "json-file" options: max-size: "100M" mem_limit: 2048m kowl: container_name: kowl # network_mode: host restart: always # image: quay.io/cloudhut/kowl:v1.5.0 image: uhub.service.ucloud.cn/marksugar-k8s/kowl:v1.5.0 restart: on-failure hostname: kowl ports: - "8081:8080" environment: KAFKA_BROKERS: 172.16.100.151:9092 volumes: - /etc/localtime:/etc/localtime:ro # 时区2 depends_on: - kafka logging: driver: "json-file" options: max-size: "100M" mem_limit: 2048m2.loggie接着参考官网helm-chart下载，而后解压，配置loggie的用例VERSION=v1.4.0 helm pull https://github.com/loggie-io/installation/releases/download/$VERSION/loggie-$VERSION.tgz && tar xvzf loggie-$VERSION.tgz根据官网的配置示例进行修改，而后得到一个如下的latest.yaml，我们关键需要定义资源配额，加速后镜像地址，外部挂载容器的实际目录image: uhub.service.ucloud.cn/marksugar-k8s/loggie:v1.4.0 resources: limits: cpu: 2 memory: 2Gi requests: cpu: 100m memory: 100Mi extraArgs: {} # log.level: debug # log.jsonFormat: true extraVolumeMounts: - mountPath: /var/log/pods name: podlogs - mountPath: /var/lib/docker/containers name: dockercontainers - mountPath: /var/lib/kubelet/pods name: kubelet extraVolumes: - hostPath: path: /var/log/pods type: DirectoryOrCreate name: podlogs - hostPath: # path: /var/lib/docker/containers path: /data/containerd # containerd的实际目录 type: DirectoryOrCreate name: dockercontainers - hostPath: path: /var/lib/kubelet/pods type: DirectoryOrCreate name: kubelet extraEnvs: {} timezone: Asia/Shanghai ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ nodeSelector: {} ## Affinity for pod assignment ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity affinity: {} # podAntiAffinity: # requiredDuringSchedulingIgnoredDuringExecution: # - labelSelector: # matchExpressions: # - key: app # operator: In # values: # - loggie # topologyKey: "kubernetes.io/hostname" ## Tolerations for pod assignment ## ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/ tolerations: [] # - effect: NoExecute # operator: Exists # - effect: NoSchedule # operator: Exists updateStrategy: type: RollingUpdate ## Agent mode, ignored when aggregator.enabled is true config: loggie: reload: enabled: true period: 10s monitor: logger: period: 30s enabled: true listeners: filesource: period: 10s filewatcher: period: 5m reload: period: 10s sink: period: 10s queue: period: 10s pipeline: period: 10s discovery: enabled: true kubernetes: # Choose: docker or containerd containerRuntime: containerd # Collect log files inside the container from the root filesystem of the container, no need to mount the volume rootFsCollectionEnabled: false # Automatically parse and convert the wrapped container standard output format into the original log content parseStdout: false # If set to true, it means that the pipeline configuration generated does not contain specific Pod paths and meta information, # and these data will be dynamically obtained by the file source, thereby reducing the number of configuration changes and reloads. dynamicContainerLog: false # Automatically add fields when selector.type is pod in logconfig/clusterlogconfig typePodFields: logconfig: "${_k8s.logconfig}" namespace: "${_k8s.pod.namespace}" nodename: "${_k8s.node.name}" podname: "${_k8s.pod.name}" containername: "${_k8s.pod.container.name}" http: enabled: true port: 9196 ## Aggregator mode, by default is disabled aggregator: enabled: false replicas: 2 config: loggie: reload: enabled: true period: 10s monitor: logger: period: 30s enabled: true listeners: reload: period: 10s sink: period: 10s discovery: enabled: true kubernetes: cluster: aggregator http: enabled: true port: 9196 servicePorts: - name: monitor port: 9196 targetPort: 9196 # - name: gprc # port: 6066 # targetPort: 6066 serviceMonitor: enabled: false ## Scrape interval. If not set, the Prometheus default scrape interval is used. interval: 30s relabelings: [] metricRelabelings: []而后调试并安装helm install loggie -f latest.yaml -nloggie --create-namespace --dry-run ./ helm install loggie -f latest.yaml -nloggie --create-namespace ./默认情况下会以ds的方式进行部署，也就是每个Node节点安装一个。[root@master-01 ~/loggie-io]# kubectl -n loggie get pod NAME READY STATUS RESTARTS AGE loggie-42rcs 1/1 Running 0 15d loggie-56sz8 1/1 Running 0 15d loggie-jnzrc 1/1 Running 0 15d loggie-k5xqj 1/1 Running 0 15d loggie-v84wf 1/1 Running 0 14d2.1 配置收集在配置收集日志之前，我们先创建一个pod，加入此时有一组pod，他的标签是app: linuxea,在kustomize中表现如下：commonLabels: app: linuxea而后开始loggie的配置。在loggie的配置可以大致理解为局部配置和全局配置，如果没有特别的要求，默认的全局配置是够用，倘若不够我们需要局部声明不同的配置信息。1，此时创建一个sink上游是kafka，ip地址是172.16.100.151:9092，我们输入类型，地址，即将创建的topic的名称apiVersion: loggie.io/v1beta1 kind: Sink metadata: name: default-kafka spec: sink: | type: kafka brokers: ["172.16.100.151:9092"] topic: "pod-${fields.environment}-${fields.topic}"but，如果这是一个加密的，你需要配置如下apiVersion: loggie.io/v1beta1 kind: Sink metadata: name: default-kafka spec: sink: | type: kafka brokers: ["172.16.100.151:9092"] topic: "pod-${fields.environment}-${fields.topic}" sasl: type: scram userName: 用户名 password: 密码 algorithm: sha2562，而在LogConfig使用的是标签来关联那些pod的日志将会被收集到，如下 labelSelector: app: linuxea # 对应deployment的标签标记有app: linuxea标签的pod均被收集3，而这些pod的日志的路径paths是pod中标准输出stdout，如果是文件目录这里应该填写对应的地址和正则匹配4，接着配置一个fields来描述资源，key:value fields: topic: "java-demo" environment: "dev"而这个自定义的描述被sink中的环境变量所提取，既：topic: "pod-${fields.environment}-${fields.topic}"5，在interceptors中我们进行了限流，这意味着每秒最多只能处理 interceptors: | - type: rateLimit qps: 900006，最后使用sinkRef关联创建的sink： sinkRef: default-kafka完整的yaml如下：apiVersion: loggie.io/v1beta1 kind: Sink metadata: name: default-kafka spec: sink: | type: kafka brokers: ["172.16.100.151:9092"] topic: "pod-${fields.environment}-${fields.topic}" --- apiVersion: loggie.io/v1beta1 kind: LogConfig metadata: name: java-demo namespace: linuxea-dev spec: selector: type: pod labelSelector: app: linuxea # 对应deployment的标签 pipeline: sources: | - type: file name: production-java-demo paths: - stdout ignoreOlder: 12h workerCount: 128 fields: topic: "java-demo" environment: "dev" interceptors: | - type: rateLimit qps: 90000 - type: transformer actions: - action: jsonDecode(body) sinkRef: default-kafka interceptorRef: default创建完成[root@master-01 ~/loggie-io]# kubectl -n loggie get sink NAME AGE default-kafka 15d [root@master-01 ~/loggie-io]# kubectl -n linuxea-dev get LogConfig NAME POD SELECTOR AGE java-demo {"app":"linuxea"} 15d日志写入后，到kafka查看的日志格式如下：{ "fields":{ "containername":"java-demo" "environment":"dev" "logconfig":"java-demo" "namespace":"linuxea-dev" "nodename":"172.16.100.83" "podname":"production-java-demo-5cf5b97645-4xh89" "topic":"java-demo" } "body":"2023-08-15T22:10:22.773955049+08:00 stdout F 2023-08-15 22:10:22.773 INFO 7 --- [ main] com.example.demo.DemoApplication : Started DemoApplication in 1.492 seconds (JVM running for ..." }3.openobserve我们需要安装openobserve，日志将会被消费到openobserve，安装openobserve在172.16.100.151的节点上version: "2.2" services: openobserve: container_name: openobserve restart: always image: public.ecr.aws/zinclabs/openobserve:latest ports: - "5080:5080" volumes: - /etc/localtime:/etc/localtime:ro # 时区2 - /data/openobserve:/data environment: - ZO_DATA_DIR=/data - ZO_ROOT_USER_EMAIL=root@example.com - ZO_ROOT_USER_PASSWORD=Complexpass#123 logging: driver: "json-file" options: max-size: "100M" mem_limit: 4096m接着我们就可以消费kafka后，将日志用vector写入到172.16.100.151上的openobserve了4.vectorvector作为替代logstash的角色，在此处的作用是消费kafka中的数据此时，我们需要配置在github的vector的releases页面下载安装包，我直接下载的rpmhttps://github.com/vectordotdev/vector/releases/download/v0.31.0/vector-0.31.0-1.x86_64.rpm安装完之后，我们需要创建一个配置文件vector.toml。格式非常简单，如下：mv /etc/vector/vector.toml /etc/vector/vector.toml-bak cat > /etc/vector/vector.toml << EOF [api] enabled = true address = "0.0.0.0:8686" [sources.kafka151] type = "kafka" bootstrap_servers = "172.16.100.151:9092" group_id = "consumer-group-name" topics = [ "pod-dev-java-demo" ] [sources.kafka151.decoding] codec = "json" [sinks.openobserve] type = "http" inputs = [ "kafka151" ] uri = "http://172.16.100.151:5080/api/pod-dev-java-demo/default/_json" method = "post" auth.strategy = "basic" auth.user = "root@example.com" auth.password = "Complexpass#123" compression = "gzip" encoding.codec = "json" encoding.timestamp_format = "rfc3339" healthcheck.enabled = false EOFbut，如果kafka加密了的话，我们需要添加额外的sasl配置[sources.kafka151] type = "kafka" bootstrap_servers = "172.16.100.151:9092" group_id = "consumer-group-name" topics = [ "pod-dev-java-demo" ] sasl.enabled = true sasl.mechanism = "SCRAM-SHA-256" sasl.password = "密码" sasl.username = "用户名" [sources.kafka151.decoding] codec = "json"对于日志的内容的处理，可以借助https://playground.vrl.dev/将上述文件替换到/etc/vector/vector.toml而后，启动systemctl start vector systemctl enable vector注意：uri = "http://172.16.100.151:5080/api/pod-dev-java-demo/default/_json",我们可以理解成http://172.16.100.151:5080/api/[group]/[items]/_json，如果在一个项目组的多个项目，我们可以通过这种方式进行归类回到openobserve查看而后点击explore查看日志回到logs查看5.openobsever搜索此时我的日志字段如下{ "fields":{ "podname":"production-java-demo-5cf5b97645-9ws4w" "topic":"java-demo" "containername":"java-demo" "environment":"dev" "logconfig":"java-demo" "namespace":"linuxea-dev" "nodename":"172.16.100.83" } "body":"2023-08-15T23:19:33.032689346+08:00 stdout F 2023-08-15 23:19:33.032 INFO 7 --- [ main] com.example.demo.DemoApplication : Started DemoApplication in 1.469 seconds (JVM running for ..." }如果我想搜索的内容是body中包含DemoApplication的内容，语法如下str_match(body, 'DemoApplication')默认情况下，只有msg,meesage,logs才会被全局匹配，对于不是这些字段的，我们需要使用str_match，如果匹配的字段是body的，包含DemoApplication的日志，可以使用如下命令str_match(body, 'DemoApplication')现在，一个可以替代传统ELK的日志方案就完成了。

2023年08月19日
347 阅读
0 评论
0 点赞

2023-08-11

linuxea: 日志收集的悄然变化日志收集短期发展史日志的查看和告警是日志收集最核心的两个原因之一，通常99%的日志都是无用的，除非这些日志被用来做数据聚合环比数据分析。而传统的ELK，无论是Logstash还是ES都是非常消耗系统资源的应用，大规模场景中，要即时消费kafka的数据是一件不太容易的事情。观测性我们知道，现在的大多数应用皆是分布式或者微服务。微服务架构是让开发人员能够更快构建和发布，而随着服务进一步扩张，我们越发的不清楚服务运行的状态。而opentelmetry是来解决这种问题手段之一，微服务扩展后自己的服务和服务依赖之间的关系，通过可观察的方式使开发和维护都能够获得对系统的可见性。为了具备这种能力，系统就需要具备观测行。观测性是用来描述对系统所发生情况的理解程度，正常运行还是已经停止，用户察觉是变快还是变慢。如何构建KPI和SLA约定指标，或者说能够接受怎么样的最坏状态。能够回答如上的这些问题，并且能够指出问题。理想情况下在中断服务之前快速响应并且快速解决。而在术语上，观测性分为：事件日志，链路追踪和聚合指标。如果听到这个，让我们想起了最近的开源领域一些状态，或许就明白了，他们在做什么小米夜莺监控Nightingale在2023.7月底发布了V6版，转而构建可观测性平台。需要时刻掌握运行状态，可能是无法避免浪费，云产品提供了昂贵的观测平台服务：阿里云的商用产品arms和腾讯的商用产品介绍到这里，我想今天的主题是从日志发展作为开始，而结束必然是与事件日志(logs)，链路追踪(traces)和聚合指标(metrics)有关。ELK的开始最早的ELK日志收集逻辑如下后来Graylog也成为更多的选择。而随着容器的发展，收集端logstash显然不够轻量，作为收集段fluentd，Fluent-bit用插件的方式比logstash更加轻便。而日志告警除开logstash，就是es插件。但是，他们都有一个同样的问题，假如你只愿意收集某一些日志，而不是所有的日志，无论是Logstash还是fluentd，Fluent-bit都i不会很轻松，你需要配置一些过滤规则或者标签，而整个配置清单至少需要100行上下。而在中间的插曲是阿里开源的 log-point，log-pilot不在对所有的pod收集，你可以通过传入环境变量的方式进行选择，这与早期阿里的平台收集日志是一样但是好景不长，log-pilot突然就停更了，它不在支持新特性和变化。事情在短期内由回到了开源领域的fluentd。而在这个过程中，有一家石墨公司推出了clickvisual，它不在使用es，而是clickhouse，因此在同配置下它的集群性能超过了ES集群并且，clickhouse的数据很容易通过ttl来进行修改删除过期数据。但是clickvisual的产品是自己公司内部使用，而后免费开源出来的，因此它的界面似乎并没有获得广大用户青睐，clickvisual社区比较清淡。但是维护人员很活跃。当然，这并没有完。除了上述这些，log-pilot在停更的2年后，阿里随后推出了新的开源项目ilogtail，但是ilogtail似乎和log-pilot的宿命一样，ilogtail的社区更多时候永远慢一些，无论是补丁还是PR合并，以及ISSUE回复，这让社区旁观的人仍然会认为这依旧是一个 KPI产品。而在ilogtail出现的同时，另一个 loggie-io悄然出现，loggie-io是网易公司的日志收集端， loggie-io与clickvisual一样，都是商业公司内部的产品，而后进行开源公开。而clickvisual和 loggie-io的维护者相对要活跃，因此使用者居多。并且 loggie-io成功了接替了没有log-pilot这些日志的空白。并且 loggie-io提供了更多的使用功能。此时的拓扑如下而在这其中，唯一没有被取代的是logstash, logstash是老牌日志处理中最关键的一环，他几乎包含了所有能够被用到的功能他都有。但是Datadog公司的vector出现后，logstash有了被替代的可能。vector是由rust编写，相比较java 的logstash使用资源更小，vector能够替代logstash的日志收集，中转，过滤，处理。它几乎可以替代logstash.事情到了这里并没有完，VictoriaLogs还没有结束，而github上openobserve通过不到一年的时间收获6K星，它的出现对标了es和kibana，因为它可以同时替代es和kibana。并声称与 Elasticsearch 相比，后者可以将日志存储成本降低约 140 倍。支持日志、指标、跟踪(Opentelemetry)，集群支持S3，警报和查询， SQL 和 PromQL。或许是得益于openobserve的parquet，openobserve声称单机每天可以处理超过 2 TB 的数据。Mac M2的处理速度为约 31 MB/秒，即每分钟处理 1.8 GB，每天处理 2.6 TB。而这种情况在上一次这样的描述的是vm存储TimescaleDB相比。而且openobserve与vm的存储都是无状态的，尽管他们并不相同，但他可以仍然水平扩展，这样一来，这一切就更加明显了。

2023年08月11日
341 阅读
0 评论
0 点赞

2023-08-08

2023年08月08日
293 阅读
0 评论
0 点赞

2022-05-15

2022年05月15日
1,684 阅读
0 评论
0 点赞

2022-03-03

2022年03月03日
1,968 阅读
0 评论
0 点赞