Fighting的博客

Linux系统下查看动态库依赖关系指令（ldd）

LDD用来打印或者查看程序运行所需的共享库,常用来解决程序因缺少某个库文件而不能运行的一些问题。ldd不是一个可执行程序，而只是一个shell脚本。使用ldd可以很方便的查看库与库之间的依赖关系，存放路径等等；对于排查链接不到库的问题很有帮助；

1、ldd命令全称
ldd命令全称为list dynamic dependencies（列出动态依赖），是Linux下常用的命令之一。它可以用来显示一个可执行文件或者共享库（动态链接库）所依赖的共享库。

2、ldd参数说明
–help 获取指令帮助信息；
–version 打印指令版本号；
-d,–data-relocs 执行重定位和报告任何丢失的对象；
-r, –function-relocs 执行数据对象和函数的重定位，并且报告任何丢失的对象和函数；
-u, –unused 打印未使用的直接依赖；
-v, –verbose 详细信息模式，打印所有相关信息；

3、简单示例

1

ldd libffi.so.7

可以看到，libffi.so.7库需要依赖libc.so.6，而libc.so.6的位置在/lib/aarch64-linux-gnu/libc.so.6 ，它的开始位置是0x0000ffff9ee7a000

4、查看缺少的依赖库
如果当前的动态库因为缺少依赖库而无法链接，那么可以通过ldd查看缺少的依赖库。

结果中可以看出，yh_ofd2img_ARRACH_64.so库需要依赖libQt5PrintSupport.so.5，而yh_ofd2img_ARRACH_64.so却找不到，方便排查。

Ambari 2.7.3 离线安装手册

准备工作

版本介绍

Ambari 2.7.3仅支持HDP-3.1.0，HDP-3.0.1，HDP-3.0.0使用以下URL确定对每个产品版本的支持https://supportmatrix.hortonworks.com/，以及下载报告

上一篇文章讲述了k8s安装Kibana，本章接着讲解K8S安装Logstash与Filebeat

Logstash和Filebeat安装

在使用k8s安装Logstash时，先在本地做测试配置，如果已经非常熟悉的，就可以将这个步骤省略

Windows安装Logstash

1. 去官方下载Windows版本的Logstash，将ZIP文件解压，变成下面的目录结构

上一篇文章讲述了k8s安装ES集群的方式，本章接着讲解K8S安装Kibana

Kibana安装

ElasticSearch 集群安装完成后，接着我们可以来部署 Kibana，这是 ElasticSearch 的数据可视化工具，它提供了管理 ElasticSearch 集群和可视化数据的各种功能。

同样首先我们使用 ConfigMap 对象来提供一个文件文件，其中包括对 ElasticSearch 的访问（主机、用户名和密码），这些都是通过环境变量配置的。对应的资源清单文件如下所示：

前言：ELK是目前主流的日志解决方案，尤其是容器化集群的今天，ELK几乎是集群必备的一部分能力；ELK在K8S落地有多种组合模式：
比如：fluentd+ELK或filebeat+ELK或log-pilot+ELK
而本文采用的是功能更强大的后者：filebeat 采集—>logstash过滤加工—>ES存储与索引—>Kibana展示的方案。

ElasticSearch 集群安装

要建立一个 Elastic 技术的监控栈，当然首先我们需要部署 ElasticSearch，它是用来存储所有的指标、日志和追踪的数据库，这里我们通过3个不同角色的可扩展的节点组成一个集群。

设计模式六大原则

单一职责原则

​ 对象不应承担太多功能，正如一心不能而用，比如太多的工作(种类)会使人崩溃。唯有专注才能保证对象的高内聚；唯有唯一，才能保证对象的细粒度。

解决问题：

　　假如有A和B两个类，当A需求发生改变需要修改时，不能导致B类出问题。

现状：

　　在实际情况很难去做到单一职责原则，因为随着业务的不断变更，类的职责也在发生着变化，即职责扩散。如类A完成职责P的功能，但是随着后期业务细化，职责P分解成更小粒度的P1与P2，这时根据单一职责原则则需要拆分类A以分别满足细分后的职责P1和P2。但是实际开发环节，若类的逻辑足够简单，可以在代码上级别上违背单一职责原则；若类的方法足够少，可以在方法级别上违背单一职责原则。

Rsync + Sersync 实现文件实时同步

概要

sersync主要用于服务器同步，web镜像等功能。基于boost1.43.0,inotify api,rsync command.开发。目前使用的比较多的同步解决方案是inotify-tools+rsync ，另外一个是google开源项目Openduckbill（依赖于inotify- tools），这两个都是基于脚本语言编写的。相比较上面两个项目，本项目优点是：

• sersync是使用c++编写，而且对linux系统文件系统产生的临时文件和重复的文件操作进行过滤，所以在结合rsync同步的时候，节省了运行时耗和网络资源。因此更快。
• sersync配置起来很简单，其中bin目录下已经有基本上静态编译的2进制文件，配合bin目录下的xml配置文件直接使用即可。
• 使用多线程进行同步，尤其在同步较大文件时，能够保证多个服务器实时保持同步状态。
• 有出错处理机制，通过失败队列对出错的文件重新同步，如果仍旧失败，则按设定时长对同步失败的文件重新同步。
• 自带crontab功能，只需在xml配置文件中开启，即可按要求隔一段时间整体同步一次。无需再额外配置crontab功能。
• 能够实现socket与http插件扩展。

K8S-证书过期问题

最近在开发环境中，在master使用kubectl get pods命令，发现报The connection to the server 172.24.2.69:6443 was refused - did you specify the right host or port?经过不断的百度和google终于把问题解决了，但网上的文章都很片面，没有具体说明处理的整个过程，下面说明一下我在整个解决问题的过程，我使用的k8s版本是1.14.1。

“WM_CONCAT”: 标识符无效

概述

11gr2和12C上已经摒弃了wm_concat函数，当时我们很多程序员在程序中确使用了该函数，导致程序出现错误，为了减轻程序员修改程序的工作量，只有通过手工创建个wm_concat函数，来临时解决该问题，但是注意，及时创建了该函数，在使用的过程中，也需要用to_char(wm_concat())方式，才能完全替代之前的应用。

浅谈系统高可用几个9

概述

经常看到各种技术文章或者分布式系统介绍说系统的可用性达到了多少个9，那么所谓”几个9“到底是怎么计算的？又意味着什么？我们简单计算分析下看看。所谓”1个9“是指90%，”2个9“是指99%，”3个9“是指99.9%，依次类推。

可用性的反面是故障时间，网站或者分布式系统会因为很多原因导致不可用，比如：程序bug；运维更新错误；环境配置升级变化；机器硬件故障；被恶意攻击；网关不小心踢掉了网线/电源插座；市政施工挖断了光纤；程序猿删库跑路；地震海啸自然灾害等等。

计算公式

如果按照年为单位计算系统的故障时间，公式如下：

故障时间秒数=(1-可用性) * 365 * 24 * 3600

计算6个9以内的情况得到如下结果：

结论

可见，如果只有1个9的可用性，体验是极其糟糕的，1年下来有1个多月不能使用。一些大型网站号称能过做到4个9，那么1年有52分钟故障时间，其实已经是不错的情况了。