node | 易学教程

实践出真知——部署ELK日志分析系统（提供包，超详细，可跟做！）

阅读更多关于实践出真知——部署ELK日志分析系统（提供包，超详细，可跟做！）

实践出真知——部署ELK日志分析系统（提供包）前言前一篇文章介绍了有关ELK日志分析系统的理论原理，本文将结合原理通过案例环境部署及配置ELK日志分析系统。环境规划使用集群方式，2个Elasticsearch节点，其中一台安装Kibana即可，另外安装Apache服务作为被监控的服务器，安装Logstash。相关规划如下表所示：主机操作系统主机名 IP地址主要安装软件服务器 Centos7.4 node1 20.0.0.140 Elasticsearch Kibana 服务器 Centos7.4 node2 20.0.0.139 Elasticsearch 服务器 Centos7.4 Apache 20.0.0.141 Logstash Apache 部署流程综述 1、检查服务器环境（推荐先进行时间同步），找到所需软件包 2、在两个elasticsearch节点上部署elasticsearch环境、elasticsearch软件、 3、检查服务是否开启并在浏览器中验证、检查健康状态与查看状态信息 4、在两个elasticsearch节点上安装elasticsearch-head插件（方便查看集群信息） 5、通过浏览器验证、检查健康状态，模拟创建索引来验证信息 6、安装Apache服务在20.0.0.141服务器上，并且安装Logstash软件 7

滑动窗口的中位数 · Sliding Window Median

阅读更多关于滑动窗口的中位数 · Sliding Window Median

［抄题］：给定一个包含 n 个整数的数组，和一个大小为 k 的滑动窗口,从左到右在数组中滑动这个窗口，找到数组中每个窗口内的中位数。(如果数组个数是偶数，则在该窗口排序数字后，返回第 N/2 个数字。) 对于数组 [1,2,7,8,5] , 滑动大小 k = 3 的窗口时，返回 [2,7,7] 最初，窗口的数组是这样的： [ | 1,2,7 | ,8,5] , 返回中位数 2 ; 接着，窗口继续向前滑动一次。 [1, | 2,7,8 | ,5] , 返回中位数 7 ; 接着，窗口继续向前滑动一次。 [1,2, | 7,8,5 | ] , 返回中位数 7 ; [暴力解法]：时间分析：空间分析：［思维问题］：不理解两个heap和窗口的大小关系：把窗口容量全扔进来，具体分到哪个格子另当别论体会到了treemap相对于heap的优越性：想 romove 哪个点是随便的。注意接口、实现都不是PQ,是 treeset 而且树状的题想想里面装的是 node 还是数字［一句话思路］：窗口移动就是加一个元素、减一个元素，用俩函数实现，所以可以放在maxheap minheap中［输入量］：空：正常情况：特大：特小：程序里处理到的特殊情况：异常情况（不合法不合理的输入）：［画图］：［一刷］：窗口满了之后romove第一个点，i - k + 1，不是第i个点，写习惯了就错了

Node系列——Node中的异常处理。

阅读更多关于 Node系列——Node中的异常处理。

3 月，跳不动了？>>> 1、对异常错误的理解异常错误应该被分为两种情况：操作失败和程序员失误 1.1、操作失败这是正确编写的程序在运行时产生的错误。它并不是程序的Bug ，反而经常是其它问题。例如：系统本身（内存不足或者打开文件数过多），系统配置（没有到达远程主机的路由），网络问题（端口挂起），远程服务（500错误，连接失败）。具体情况如下：连接不到服务器无法解析主机名无效的用户输入请求超时服务器返回500 套接字被挂起系统内存不足 1.2、程序员失误这是程序里的Bug。这些错误往往可以在调试阶段通过修改代码避免。它们永远都没法被有效的处理，而是应该在程序员变编程的时候注意，例如：读取 undefined 的一个属性调用异步函数没有指定回调该传对象的时候传了一个字符串该传IP地址的时候传了一个对象 1.3、二者的差别对比人们把操作失败和程序员的失误都称为“错误”，但其实它们很不一样。操作失败是所有正确的程序应该处理的错误情形，只要被妥善处理它们不一定会预示着Bug或是严重的问题。“文件找不到”是一个操作失败，但是它并不一定意味着哪里出错了。它可能只是代表着程序如果想用一个文件得事先创建它。与之相反，程序员失误是彻彻底底的Bug。这些情形下你会犯错：忘记验证用户输入，敲错了变量名，诸如此类。这样的错误根本就没法被处理，如果可以

Java中的阻塞队列LinkedBlockingQueue

阅读更多关于 Java中的阻塞队列LinkedBlockingQueue

目录 1.LinkedBlockingQueue介绍 1.1BlockingQueue接口 1.2LinkedBlockingQueue 1.3LinkedBlockingQueue原理与数据结构 2.LinkedBlockingQueue源码分析 2.1创建 2.2put方法 2.3take方法 1.LinkedBlockingQueue介绍 1.1BlockingQueue接口同ArrayBlockingQueue一样，LinkedBlockingQueue同样实现了BlockingQueue接口。 1.2LinkedBlockingQueue LinkedBlockingQueue LinkedBlockingQueue是一个单向链表实现的阻塞队列。 LinkedBlockingQueue可以在创建时指定容量大小，防止队列过度膨胀。如果未指定队列容量，默认容量大小为Integer.MAX_VALUE。 1.3LinkedBlockingQueue原理与数据结构说明： (01) head是链表的表头。取出数据时，都是从表头head处取出，出队。 (02) last是链表的表尾。新增数据时，都是从表尾last处插入，入队。 (03) count是链表的实际大小，即当前链表中包含的节点个数。 (04) capacity是列表的容量，它是在创建链表时指定的。 (05)

vue 访问页面时报错 Failed to compile

阅读更多关于 vue 访问页面时报错 Failed to compile

这个是因为node-sass没安装好，所以要重新安装 windows下运行命令：npm install node-sass --registry=https://registry.npm.taobao.org 来源： https://www.cnblogs.com/syingBlog/p/12580163.html

Python3标准库：xml.etree.ElementTree XML操纵API

阅读更多关于 Python3标准库：xml.etree.ElementTree XML操纵API

1. xml.etree.ElementTree XML操纵API ElementTree库提供了一些工具，可以使用基于事件和基于文档的API来解析XML，可以用XPath表达式搜索已解析的文档，还可以创建新文档或修改现有文档。 1.1 解析XML文档已解析的XML文档在内存中由ElementTree和Element对象表示，这些对象基于XML文档中节点嵌套的方式按树结构互相连接。用parse()解析一个完整的文档时，会返回一个ElementTree实例。这个树了解输入文档中的所有数据，另外可以原地搜索或操纵树中的节点。基于这种灵活性，可以更方便的处理已解析的文档，不过，与基于事件的解析方法相比，这种方法往往需要更多的内存，因为必须一次加载整个文档。对于简单的小文档(如下面的播客列表，被表示为一个OPML大纲)，内存需求不大。 podcasts.opml： <?xml version="1.0" encoding="UTF-8"?> <opml version="1.0"> <head> <title>My Podcasts</title> <dateCreated>Sat, 06 Aug 2016 15:53:26 GMT</dateCreated> <dateModified>Sat, 06 Aug 2016 15:53:26 GMT</dateModified> <

C++ 单链表的冒泡排序

阅读更多关于 C++ 单链表的冒泡排序

#define _CRT_SECURE_NO_WARNINGS #include <stdio.h> #include <stdlib.h> struct Node { int id; Node* next; }; //初始化头节点 Node* init_m_head() { Node* temp = (Node*)malloc(sizeof(Node)); temp->id = 0; temp->next = NULL; return temp; } //初始化子节点 Node* init_Node(int num) { Node* temp= (Node*)malloc(sizeof(Node)); temp->id = num; temp->next = NULL; return temp; } //节点链接 void nodelink(Node* n1, Node* n2) { n2->next = n1->next; n1->next = n2; } //节点交换 void swap(Node* n1, Node* n2) { Node* temp = n1; n1 = n2; n2 = temp; } //void maopao(Node* list) // { // Node* temp = list->next; // Node* pre = list; //

51、Kubernetes 系统基础

阅读更多关于 51、Kubernetes 系统基础

51.1、kubernetes介绍： 1、什么是kubernetes：（1）Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。（2）使用Kubernetes可以： 1）自动化容器的部署和复制 2）随时扩展或收缩容器规模 3）将容器组织成组，并且提供容器间的负载均衡 4）很容易地升级应用程序容器的新版本 5）节省资源，优化硬件资源的使用 6）提供容器弹性，如果容器失效就替换它 2、kubernetes的特点：（1）便携性：支持公有云、私有云、混合云、多重云(multi-cloud) （2）可扩展：模块化、插件化、可组合、可挂载（3）自修复：自动部署，自动重启，自动复制，自动伸缩扩展 3、kubernetes特性： Kubernetes是一种用于在一组主机上运行和协同容器化应用程序的系统，旨在提供可预测性、可扩展性与高可用的性的方法来完全管理容器化应用程序和服务的生命周期的平台。（1）自动装箱：构建于容器之上，基于资源依赖及其他约束自动完成容器部署且不影响其可用性，并通过调度机制混合关键型应用和非关键型应用的工作负载于同一节点以提升资源利用率。（2）自我修复：支持容器故障后自动重启、节点故障后重行调度容器，以及其他可用节点、健康状态检查失败后关闭容器并重新创建等自我修复机制。（3）水平扩展

ConcurrentHashMap（1.8）相关整理

阅读更多关于 ConcurrentHashMap（1.8）相关整理

1. ConcurrentHashMap 1.1 HaspMap（JDK 1.8） JDK 1.8 HashMap JDK 1.8 对 HashMap 进行了修改，最大的不同就是利用了红黑树，其由数组+链表+红黑树组成。 JDK 1.7 中，查找元素时，根据 hash 值能够快速定位到数组的具体下标，但之后需要顺着链表依次比较才能查找到需要的元素，时间复杂度取决于链表的长度，为 O(N) 。为了降低这部分的开销，在 JDK 1.8 中，当链表中的元素超过 8 个以后，会将链表转换为红黑树，在这些位置进行查找的时候可以降低时间复杂度为 O(logN) 。 JDK 1.8 使用 Node（1.7 为 Entry）作为链表的数据结点，仍然包含 key，value，hash 和 next 四个属性。红黑树的情况使用的是 TreeNode。根据数组元素中，第一个结点数据类型是 Node 还是 TreeNode 可以判断该位置下是链表还是红黑树。核心成员变量于 1.7 类似，增加了核心变量，如下表。属性说明 TREEIFY_THRESHOLD 用于判断是否需要将链表转换为红黑树的阈值，默认为 8。 put 方法过程 public V put(K key, V value) { return putVal(hash(key), key, value, false, true);

Docker版zabbix

阅读更多关于 Docker版zabbix

1. docker-compose docker-compose ：容器自带的编排工作，可以通过yaml编排文件，将容器要启动的命令写入文件，然后再利用docker-compose run file.yaml文件来直接启动，同时启动多个容器，方便应用服务的移植、共享。 2. 部署zabbix服务部署zabbix服务，然后利用docker-compose启动。 1> 上传压缩包，解压 [root@node ~]# cd /opt/ [root@node opt]# ls rh zabbix-agent.tar.gz zabbix-server.tar.gz [root@node opt]# tar xf zabbix-server.tar.gz [root@node opt]# ls cmp_mariadb cmp_zabbix rh zabbix-agent.tar.gz zabbix-server.tar.gz 2> 启动数据库 [root@node cmp_mariadb]# docker load -i mariadb-latest.tar #导入镜像 [root@node cmp_mariadb]# docker images mariadb latest 901583bfdf5a 5 months ago 367MB 启用编排文件文件名必须为docker-compose

订阅 node