青蛙小白
#Linux

通过 Linux 块设备统计信息监控 OpenStack Cinder 卷迁移进度

背景 在 OpenStack 私有云环境中，Cinder 卷迁移是一个常见的运维操作。当需要对存储后端进行维护、升级，或者需要在不同存储池之间平衡负载时，都会涉及到卷迁移。 然而 Cinder API 在卷迁移方面存在一个明显的不足：它不提供实时的迁移进度信息。当你执行 cinder migrate 命令后，只能通过 cinder show <volume-id> 查看卷的 migration_status 字段，而这个字段只会显示 migrating 或 success/error 这样的状态，无法得知当前已经迁移了多少数据，还需要等待多长时间。

#Prometheus

使用Prometheus的blackbox_exporter进行网络监控

Prometheus提供了一个blackbox_exporter可以实现网络监控，支持http、dns、tcp、icmp等监控。 blackbox_exporter的配置 blackbox_exporter以下面的命令运行： blackbox_exporter --web.listen-address=:9115 --config.file=blackbox.yml 其中9115是这个exporter的http端点的监听端口，blackbox.yml是它的配置文件，需要在其中使用blackbox_exporter的http、dns、tcp、icmp等prober定制配置出各种监测模块(module)。关于blackbox_exporter的配置具体参考Blackbox exporter configuration和Blackbox exporter configuration Exmaple。下面的例子是一个最基本的配置：

#Kubernetes #Docker

Kubernetes Pod无法删除,Docker: Device is busy问题的解决

问题发现 最近测试环境Kubernetes集群的两台主机重启后，发现这两台主机上(CentOS 7.3)的Pod无法删除。 发现这个问题的经过如下： 某个服务的自动发布触发后，监控系统告警有Pod处于Terminated状态，具体去查看发现前面重启过的两台主机上因为服务发布需要被删掉的Pod一直处于Terminated: ExitCode状态。因为是测试环境，开始没有特别关注，而是直接使用kubectl delete pod <podname> --namespace=<namspacer> --grace-period=0 --force尝试将有问题Pod强制删除，结果强制删除不起作用。马上觉得问题可能没有那么简单，于是分别登录到这两台主机上通过docker ps -a查看对应docker容器的状态，发现这两个Pod的docker容器处于Dead状态。使用docker rm <container id>，提示Device is Busy，无法删除。

#Elasticsearch

使用Curator管理Elasticsearch的索引

Curator是一个用来管理Elasticsearch索引的工具，使用它可以管理需要删除或保留的索引数据。 当Elasticsearch作为ELK、EFK等日志收集方案的日志存储时，删除过期数据以释放存储空间显的格外重要，使用Curator可以删除旧的索引并优化系统。 1.Curator的功能 使用Curator可以完成以下功能： 为别名(Alias)添加或移除索引 创建索引 删除索引 关闭索引 删除快照 打开已经关闭的索引 更改分片路由配置 强制合并索引 重建索引(包括从远程的集群) 更改索引每个分片的副本数量 为索引创建快照 从快照还原 rollover indices(当某个别名指向的实际索引过大的时候，自动将别名指向下一个实际索引) 2.安装Curator 安装Curator十分简单，可以通过python pip工具来完成。

#Istio

Istio学习的开始(四)：Istio的架构

Istio中的官方文档中对Istio的架构做了介绍。下图是文档中的Istio架构示意图： istio-arch.jpg Istio在逻辑上分为数据平面(data plane)和控制平面(control plane)两块。 控制平面 控制平面对Service Mesh具有强大的控制力。Istio的控制平面由包括以下组件： Pilot(领航员)：为envoy sidecar提供服务发现，为流量管理功能实现了灵活的路由（如A/B测试,金丝雀发布)和弹性(如：超时,重试,熔断等)。它将高级别的路由规则转换为envoy特定的配置并在运行时将配置传播到sidecar中。 Mixer(混合器)：Mixer是一个平台独立的组件，它的职责是在ServiceMesh上实施访问控制和使用策略(usage policies)，并从envoy代理和其它服务中收集自动测量数据。 Istio-Auth：使用强大的健服务之间以及服务和终端用户间的认证。可以将ServiceMesh中未加密的流量升级，并为运维人员提供基于服务标识而非网络控制的策略管理能力。 数据平面 Envoy是Istio的数据平面。Envoy早已经是CNCF的ServiceMesh项目之一，功能强大和稳定。Envoy适合使用sidecar模式部署为服务的Proxy。Envoy使用C++开发在性能和资源消耗上优于CNCF的另一个ServiceMesh项目linkerd。Envoy接管服务网格中所有服务的进出流量。Istio实际上利用了很多Envoy已有的特性，例如：服务的动态发现、负载均衡、TSL终止、HTTP/2和gRPC代理、断路器、健康检查、流量拆分、故障注入以及丰富的度量指标。

#Prometheus #Redis

使用Prometheus监控Redis

使用Prometheus监控Redis，推荐使用https://github.com/oliver006/redis_exporter这个exporter。 目前我们主要使用的是redis的主从复制搭配Sentinel实现的高可用方案。部署形式上有两种：一种形式是使用ansible部署在物理机器上，同样使用ansible在相同的机器上部署redis_exporter；另外一种形式是redis和sentinel以StatefulSet的形式跑在Kubernetes上，redis_exporter以sidecar容器的形式和redis容器在相同的Pod里。

#Prometheus

Prometheus监控实践：使用Prometheus监控Java应用

之前在《Prometheus监控实践：Kubernetes集群监控》一本中总结了我们目前基于Prometheus对Kubernetes集群的监控，除了监控Kubernetes集群本身的关键指标之外，也对部署在Kubernetes集群上应用的状态做了监控。 对于Kubernetes集群上Pod, DaemonSet, Deployment, Job, CronJob等各种资源对象，我们通过kube-state-metrics作为Prometheus的exporter完成了对这些Kubernetes资源对象的监控。而为了使监控深入到应用的内部，就需要应用自身暴露作为Exporter暴露监控指标，这就和应用的开发语言和技术框架紧密相关了。 我们目前部署在Kubernetes上的微服务主要是由Go和Java两种语言开发的，本篇将总结一下目前我们使用Prometheus对Java应用的监控实践。