mutoulazy's space

kubernetes 持久化的存储方式emptyDiremptyDir类型的Volume在Pod分配到Node上时被创建，Kubernetes会在Node上自动分配一个目录，因此无需指定宿主机Node上对应的目录文件。 这个目录的初始内容为空，当Pod从Node上移除时，emptyDir中的数据会被永久删除。注：容器的crashing事件并不会导致emptyDir中的数据被删除。 使用场景 临时空间，例如基于磁盘的合并排序 设置检查点以从崩溃事件中恢复未执行完毕的长计算 保存内容管理器容器从Web服务器容器提供数据时所获取的文件 例子123456789101112131415apiVersion: v1kind: Podmetadata: name: test-podspec: containers: - image: busybox name: test-emptydir command: [ "sleep", "3600" ] volumeMounts: - mountPath: /data name ...

prometheus中如何过滤不需要的指标在prometheus的采集中会发现一个job中可能包含几十上百个指标，而每个指标的下的数据量也很大。在生产环境中我们实际上用的到指标可能只有几十个，而哪些被prometheus采集过来我们又没有用到的指标就成了浪费部署资源的元凶。这个时候我们就要考虑对prometheus采集的job中指标进行过滤。 如何查询指标下数据量的情况12345# 展现数据量前50的指标topk(50, count by (__name__, job)({__name__=~".+"}))# prometheus中的指标数据量sum(count by (__name__, job)({__name__=~".+"})) 过滤prometheus 采集Job上的指标下面以cadvice采集job为例子，目前采用的是metric_relabel_configs下的drop操作,丢弃不需要的指标(感觉不是特别方便) 123456789101112131415161718192021222324 ...

解决在prometheus-opretor中部署的node-export采集主机根目录数据不正常的问题问题描述在采用prometheus-opretor默认的配置部署完成整个prometheus环境监控时，发现部分集群节点上的主机磁盘使用情况和总容量等指标的数据不准确。涉及的指标有：node_filesystem_avail_bytes、node_filesystem_size_bytes等 问题起因思考由于chart部署的node-export采用的是docker部署的形式官方推荐的是二进制程序的本机安装，但考虑到部署和后期运维的便捷性还是决定采用docker部署在查询官方的gitbub的页面时,发现如果需要docker部署要设置相关监控路径的目录的挂载和绑定而在默认的chart脚本中是没有相关参数的配置，所以要手动加上 1234567# 官方参看docker部署命令docker run -d \ --net="host" \ --pid="host" \ -v "/:/host:ro,rslave" \ quay. ...

Prometheus-operator 采用动态PV持久化持久化的重要性Prometheus-operator 中的Prometheus需要进行持久化操作否则一旦重启就会导致所有性能数据丢失 持久化方式的选择查找Prometheus-operator的 value.yaml文件 发现有个storageSpec配置 采用的是storageClass 动态PV持久化关于是否支持其他形式的持久化需要进一步的研究(也可以使用local volume PVC) value.yaml的storageSpec配置123456789storageSpec: volumeClaimTemplate: spec: storageClassName: prometheus-data accessModes: ["ReadWriteOnce"] resources: requests: storage: 30Gi # selector: {& ...

Prometheus-operator 添加自定义采集规则的方法部署前在chart value文件中自定义采集规则在新的prometheus-opreator chart脚本中如果要新增自定义采集规则就要修改chart value.yaml文件中的 additionalScrapeConfigs 部分 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667# PO chart 的部分内容## AdditionalScrapeConfigs allows specifying additional Prometheus scrape configurations. Scrape configurations## are appended to the configurations generated by the Prometheus Operator. Job configurations m ...

Prometheus-operator获取kubelet指标失败的解决方法问题描述使用Prometheus-operator chart搭建完成后发现部分集群的kubelet采集job拉取指标失败显示500错误 问题可能发生的原因由于k8s集群各个节点未开启kubelet组件采集的权限导致 问题解决参考链接修改各个节点位于/etc/systemd/system/kubelet.service.d/10-kubeadm.conf位置的kubelet配置文件修改命令如下，记得修改前进行配置文件的备份 1234567KUBEADM_SYSTEMD_CONF=/etc/systemd/system/kubelet.service.d/10-kubeadm.confsed -e "/cadvisor-port=0/d" -i "$KUBEADM_SYSTEMD_CONF"if ! grep -q "authentication-token-webhook=true" "$KUBEADM_SYSTEMD_CONF"; ...

java内存区域1 运行时数据区域线程私有的: 程序计数器 虚拟机栈 本地方法栈 线程共享的: 堆 方法区 直接内存 1.1 程序计数器字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完。为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。注意：程序计数器是唯一一个不会出现OutOfMemoryError的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。 1.2 Java 虚拟机栈与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期和线程相同，描述的是 Java 方法执行的内存模型。Java 内存可以粗糙的区分为堆内存（Heap）和栈内存(Stack),其中栈就是现在说的虚拟机栈，或者说是虚拟机栈中局部变量表部分。（局部变量表主要存放了编译器可知的各种数据类型（boolean、byte、char、short、int、float、long ...

1 什么是乐观锁总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。 2 什么是悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。 3 两种锁的适用场景乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果 ...

Java集合类CollectionList ArrayList Object数组,线程不安全 Vector Object数组,线程安全 LinkedList 双向链表(JDK1.6之前为循环链表，JDK1.7取消了循环) Set HashSet 无序 唯一 基于HashMap实现的，底层采用HashMap来保存元素 LinkedHashSet LinkedHashSet继承与HashSet，并且其内部是通过LinkedHashMap来实现的 TreeSet 有序 唯一 内部基于红黑树 Map HashMapJDK1.8之前HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）.JDK1.8以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间 LinkedHashMapLinkedHashMap 继承自 HashMap，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，LinkedHashMap在上面结构的基础上，增加了一条双向链表，使得上面 ...

1 2 3 4 5 6 7 8 9 10