InfluxDB

关注公众号 MageByte，设置星标获取最新推送。公众号后台回复 “加群” 进入技术交流群获更多技术成长。 时间序列数据库(TSDB)初识与选择 背景 这两年互联网行业掀着一股新风，总是听着各种高大上的新名词。大数据、人工智能、物联网、机器学习、商业智能、智能预警啊等等。 以前的系统，做数据可视化，信息管理，流程控制。现在业务已经不仅仅满足于这种简单的管理和控制了。数据可视化分析，大数据信息挖掘，统计预测，建模仿真，智能控制成了各种业务的追求。 “所有一切如泪水般消失在时间之中，时间正在死去“ ，以前我们利用互联网解决现实的问题。现在我们已经不满足于现实，数据将连接成时间序列，可以往前可以观其历史，揭示其规律性，往后可以把握其趋势性，预测其走势。 于是，我们开始存储大量时间相关的数据(如日志，用户行为等)，并总结出这些数据的结构特点和常见使用场景，不断改进和优化，创造了一种新型的数据库分类——时间序列数据库(Time Series Database). 时间序列模型 时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。 每个时序点结构如下： timestamp: 数据点的时间，表示数据发生的时间。 metric: 指标名，当前数据的标识，有些系统中也称为name。 value: 值，数据的数值

[ ] 事件告警产生的背景 [ ] 阿里kube-event介绍、支持的通知程序 [ ] k8s1.16.3集群对接钉钉机器人实践 背景 监控是保障系统稳定性的重要组成部分，在Kubernetes开源生态中，资源类的监控工具与组件监控百花齐放。 cAdvisor：kubelet内置的cAdvisor，监控容器资源，如容器cpu、内存； Kube-state-metrics：kube-state-metrics通过监听 API Server 生成有关资源对象的状态指标，主要关注元数据，比如 Deployment、Pod、副本状态等； metrics-server：metrics-server 也是一个集群范围内的资源数据聚合工具，是 Heapster 的替代品，k8s的HPA组件就会从metrics-server中获取数据； 还有node-exporter、各个官方、非官方的exporter，使用 Prometheus 来抓取这些数据然后存储，告警，可视化。但这些还远远不够。 监控的实时性与准确性不足 大部分资源监控都是基于推或者拉的模式进行数据离线，因此通常数据是每隔一段时间采集一次，如果在时间间隔内出现一些毛刺或者异常，而在下一个采集点到达时恢复，大部分的采集系统会吞掉这个异常。而针对毛刺的场景，阶段的采集会自动削峰，从而造成准确性的降低。 监控的场景覆盖范围不足

BUG 1号 相关定义： org.influxdb:influxdb-java:2.14.0 - influx-A org.influxdb:influxdb-java:2.16.0 - influx-B 现象：出现异常，显示metric为乱码 原因：flink的metrics中存在【NaN和Inf】的情况 根本原因： influx-A 中没有提供对【NaN和Inf】情况的处理 处理：调整flink-metrics-influxdb使其依赖 Influx-B BUG 2号 相关定义： com.squareup.moshi:moshi:1.15.0 - M-A com.squareup.moshi:moshi:1.18.0 - M-B 现象：出现异常，显示NoSuchMethodException(okio.BufferedSource.getBuffer()) 原因： Influx-B 中依赖了 M-B ，而 M-B 中 调用了getBuffer方法，从而触发了该异常 处理：调整flink-metrics-influxdb使其依赖 Influx-B ，并覆盖对 M 的依赖，使其依赖 M-B 来源： CSDN 作者： Han.启书 链接： https://blog.csdn.net/weixin_34874025/article/details/104574889

InfluxDB Enterprise集群安装实验01-简介 前言 近期公司打算采购InfluxDB的企业版集群，正好抽空自己搭一套练练手，测试下基本功能。 实验环境 操作系统：CentOS Linux release 7.3.1611 (Core) influxdb版本：1.7.9 机器： 机器名 ip influxdb01 10.11.100.73 influxdb02 10.11.100.74 influxdb03 10.11.100.75 前置条件 1.秘钥配置要求 influxdb的秘钥配置有license key和license file两种方式，如果使用license key进行秘钥验证，则必须保证所有节点都能访问门户网站portal.influxdata.com的80端口或443端口。如果超过4小时无法连接到门户网站将导致秘钥验证失败的问题，整个集群将不可用。 注意：个人建议在生产中使用license file的验证方式，可以避免由于外部网络波动导致的集群故障 2.确保各主机的连接 集群中的所有机器需要确保主机名与ip的相互解析，并确保网络通畅。 在所有机器的hosts文件加上主机名： [root@influxdb01 opt] # cat /etc/hosts 10 . 11 . 100 . 73 influxdb01 10 . 11 . 100 . 74

本人写的这篇文章主要是介绍java如何使用influxDB时序数据库，具有一定的参考价值，感兴趣的小伙伴们可以参考一下。 废话不多说，直接上代码： 1、pom.xml引入相关jar文件，如下： <!-- 引入influxdb依赖 --> <dependency> <groupId>org.influxdb</groupId> <artifactId>influxdb-java</artifactId> <version>2.8</version> </dependency> 2、influxDB工具类封装： package com.mt.core.util; import java.util.List; import java.util.Map; import java.util.concurrent.TimeUnit; import org.influxdb.InfluxDB; import org.influxdb.InfluxDB.ConsistencyLevel; import org.influxdb.InfluxDBFactory; import org.influxdb.dto.BatchPoints; import org.influxdb.dto.Point; import org.influxdb.dto.Point.Builder; import org

文章目录 简单例子 详细API InfluxDBClient InfluxDBClient类的参数说明 InfluxDB类的方法 DataFrameClient DataFrameClient类的参数说明 DataFrame类的方法 详细例子 InfluxDBClient例子 DataFrameClient例子 简单例子 from influxdb import InfluxDBClient client = InfluxDBClient ( 'localhost' , 8086 , 'aiops_logwarn' ) # 连接数据库 client . create_database ( 'example' ) # 创建数据库 points = [ # 待写入数据库的点组成的列表 { "measurement" : "cpu_load_short" , "tags" : { "host" : "server01" , "region" : "us-west" } , "time" : "2009-11-10T23:00:00Z" , "fields" : { "value" : 0.64 } } ] client . write_points ( points , database = 'example' ) # 将这些点写入指定database # 查询刚刚写入的点 result

前提 Docker 前言 现在Docker Swarm已经彻底输给了K8S,但是现在K8S依然很复杂，上手难度较Docker Swarm高，如果是小规模团队且需要容器编排的话，使用Docker Swarm还是适合的。 目前Docker Swarm有一个问题一直没有解决，如果业务需要知道用户的请求IP,则Docker Swarm满足不了要求。目前部署在Docker Swarm内的服务,无法获取到用户的请求IP。 具体可以看看这个ISSUE-> Unable to retrieve user's IP address in docker swarm mode 整体思路 思路整体来说是使用Influxdb+Grafana+cadvisor,其中 cadvisor 负责数据的收集，每一台节点都部署一个cadvisor服务,Influxdb负责数据的存储,Grafana负责数据的可视化。 演示环境 主机 IP master(manager) 192.168.1.60 node1(worker) 192.168.1.61 node2(worker) 192.168.1.62 我这里是将master节点当作监控数据存储以及可视化服务的节点作为演示,一般是拿一个worker节点做这样的工作。 初始化Docker Swarm 在master机器上初始化集群,运行 docker swarm init

本人浅析传统IT系统层面的系统监控，不涉及k8s以及Service Mesh，抛砖引玉。 随着系统增多，我们需要一套能够立体化监控系统去监控你的应用及业务，出现问题能够及时告警，或通过大屏、短信和邮件。 我个人认为监控应该从三个方面进行入手，即：Metrics、Logging、Tracing。 Metrics （指标） 通常指标信息担负着数据可视化的物料信息，比如：计量器、直方图、计数器、TPS等等。 Logging（日志） 日志信息通常记录了应用程序运行时的详细状态信息。通常会有INFO、WARN、ERROR等级别。 Tracing（追踪） 在传统的单体应用，如传统的MVC系统中，通常访问逻辑明确。而使用微服务对系统进行重新设计之后，就会带来接口互调，多线程，应用多活情况下的调用次序不明等种种问题。这时迫切需要记录每次请求都经过了哪些主机的那些服务，以及是一次调用会带来系统内部的多次调用问题。以及Http传输协议的天然低效率问题，都是需要在追踪层面上做考虑的。 监控选型与架构： Metrics （指标）: Promethues+Grafanna+Influxdb Logging（日志）: ELK or Spark Streaming Tracing（追踪）: Zipkin or Skywalking 欢迎关注我的公号：彪悍大蓝猫，持续分享SpringCloud、大数据干货~ 来源

IoTDB 是一款时序数据库，相关竞品有 Kairosdb ， InfluxDB ， TimescaleDB 等，主要使用场景是在 物联网 相关行业，如：车联网、风力发电、地铁、飞机监控等等，具体应用案例及公司详情可以查看： IoTDB在实际公司中的使用信息收集 IoTDB 模块主要分为 Client ， JDBC ， Server ， TsFile ， Grafana ， Distribution 以及各种生态的 连接器 。整个系列的文章会从行业背景开始讲起，了解一个行业具体的使用场景，然后介绍 TsFile 是以什么样的格式来保存数据的，再介绍 Server 里怎样完成一次查询，最后在介绍一条完 整的 SQL 是怎样从 Client 使用 JDBC 到 Server 直至返回具体结果。如果有能力的话再介绍一下集群的一些内容和工作方式。 打一波广告本人专注车联网领域多年，现任四维智联架构师。目前正在参与 IoTDB 社区，有志同道合的同伴欢迎加微信： liutaohua001 欢迎大家访问 IoTDB 仓库 ，求一波 Star 。 这一章主要想聊一聊： 为什么重复造轮子，从物联网行业的数据特点到 IoTDB 的发展过程 这个轮子造的怎么样， IoTDB 和竞品测试对比 时序数据 我个人理解时序数据是基于时间维度的同一个物体或概念的值构成的一个序列数据。在传统关系型数据库中，例如