技巧:普及一下定向获取某些网站源码的操作过程

　　技巧:普及一下定向获取某些网站源码的操作过程

　　几年前，我在做外贸的时候，试过很多次。当然，如果你指定了某个网站的源码，那就很难了，你需要踩着它去挖掘各种东西。

　　几年前，我在做外贸。比如我需要网站的nike jordans shoes，我会分批采集，然后进行批量漏洞扫描。

　　当然，今天的介绍与上一篇类似。

　　首先确保 关键词

　　下载免费的高级主题

　　免费的wordpress主题

　　无效的 PHP 脚本

　　无效的 WordPress 主题

　　无效的 WordPress 插件

　　采集目标网站

　　这里我有3种方法，一种是用谷歌搜索引擎搜索，当然你也可以BING、YAHOO等。有这样的软件，可以批量实现。

　　另一个是semrush。

　　最后一个是大数据平台数据采集。

　　semrush关键词搜索采集

　　ORGANIC SEARCH RESULTS 下有一个导出，我们直接导出到 csv 文件

　　同样的方法，我们也导出同样的其他关键词，CSV我会分享到小圈子里。

　　semrush采集竞争对手方式

　　通过查找此类型的 网站competitors网站 获取 网站 列表并导出

　　以此类推，我们可以得到很多 网站 的 网站 列表。这些数据样本，我还是会在小圈子里提供。

　　搜索引擎采集

　　我之前推过这个软件，但是有人吐槽我推的垃圾，哎。别无选择。

　　今天顺便演示一下软件的采集操作。

　　1 打开软件，选择选项

　　2 选择工具，然后选择在线搜索网站或在线搜索网站列表

　　3 输入您的 关键词 并选择搜索引擎

　　软件支持811搜索引擎，也支持代理搜索。

　　我们导出我们搜索的所有内容，包括软件识别的 cms 类别

　　像这样。

　　fofa.so 采集

　　浏览一些 关键词，找到 网站，然后导出。

　　网址排序

　　定期提取域名，去掉一些URL的小尾巴，然后去重，删除重复的。我这里就不做详细演示了，很简单。

　　如何获取源代码

　　最简单的就是扫描压缩包，然后判断网站的cms的类型，然后根据cms的类型进行漏洞攻击。其他的就是侧站，跨站，或者扫描服务器是否有漏洞，入侵，入侵的方法有很多种，这里我还是介绍最简单的方法。

　　扫描默认档案

　　小米圈也分享了这个软件，之前是52pojie发现的，叫网元侦探，有破解版。

　　总之，我们已经获得了大量的源码，这里就不继续等他扫描完了。

　　完整解决方案:微服务架构下的监控系统设计（一）——指标数据的采集展示

　　前言

　　微服务是一种架构风格，大型复杂的软件应用程序通常由多个微服务组成。系统中的每个微服务都可以独立部署，每个微服务都是松耦合的。每个微服务只专注于完成一项任务并把它做好。

　　在微服务之前，很多单体应用的监控复杂度较低，场景相对简单。在微服务下，由于业务逻辑分散在很多流程中（很多大业务，一个业务流程涉及几十个服务），一旦出现业务问题，追根溯源就像大海捞针。这时就需要一个完整的监控系统。

　　一套完整的监控系统建设周期长，需要随着业务场景的变化进行迭代优化。本文仅从几个监控维度和原子场景探讨如何建立统一的监控数据采集和展示系统，希望能启发大家继续深入思考监控系统的建设。

　　微服务下的几个监控维度

　　与传统应用的监控相比，微服务监控最明显的变化就是视角的变化。我们将监控从机器角度转换为以服务为中心的角度。从微服务的角度来看，监控可以从数据维度和资源维度来看。与代码维度分层，如下图：

　　数据维度

　　目前，WEB服务是主流。每一个WEB服务都有一个入口，无论是APP还是WEB页面，入口负责与用户交互，并将用户的信息发送到后台。一般后台会访问LB或者Gateway，负责负载。将数据均衡转发给特定的应用程序进行处理，最后在应用程序处理完毕后写入数据库。

　　资源维度

　　现在很多服务都部署在云端，涉及到虚拟化技术，虚拟主机运行在物理服务器上，虚拟主机之间通过虚拟网络相互连接。资源层面的监控是不可或缺的一环。我们不仅需要采集虚拟主机的性能指标，还需要知道运行虚拟主机的服务器的CPU、内存、磁盘IO等数据，以及连接的虚拟主机。主机之间的虚拟网络带宽负载等。

　　代码维度

　　APM，即应用性能分析、代码端监控采集，是随着微服务的兴起而出现的。在微服务场景下，一个业务流程跨越数十个服务，仅靠传统的监控数据很难定位问题的根源。

　　我们可以针对代码的技术栈开发具体的采集框架，在可接受的性能损失范围内，采集函数之间的调用关系，服务之间的调用拓扑，只测量响应时间功能或服务的性能可以优化性能或提前预测故障。

　　关键监控指标场景描述

　　微服务监控的最大特点可以用一句话概括：服务很多，服务之间的调用也很复杂。当系统出现问题时，要想在数百个相关的错综复杂的业务系统中快速定位故障系统，就需要依靠关键的监控指标。基于以上三个维度，我们分析了各个维度下各个层级可能产生的告警，总结出URL监控、主机监控​​、产品监控等8个原子监控场景。

　　URL监控：无论是APP还是WEB，本质上都是通过URL发起后台调用。您可以通过MOCK调用API获取响应时间、响应状态码等指标，展示监控业务的整体健康状况。

　　主机监控：通过安装agent采集对主机的基本监控信息如CPU、内存、IO等数据，用户可以通过配置文件打开其他开源应用如Tomcat、Nginx等数据采集 开关。

　　产品监控：公有云以产品的形式向用户提供主机、网络、存储和一些中间件。产品服务后台上报每个产品的相关指标数据，监控每个产品资源的健康状况。

　　组件监控：一些开源组件，如Tomcat、Nginx、Netty等监控数据采集，可以通过宿主机上的代理加载对应组件的监控采集程序。

　　自定义监控：服务实例采集业务相关数据，定时调用API接口上报数据，支持多个服务实例同时上报一个监控项，支持多维度查询告警。

　　资源监控：用户根据资源报告自定义数据。每个资源都有相同的几个监控项，每个资源的监控项相互独立。

　　APM：根据语言栈的不同，分别展示服务之间的函数调用关系和调用拓扑。根据语言的不同，有的需要破解代码并以SDK嵌入的形式采集数据，有的则与代码解耦，有的方法通过元编程重载实现data采集。

　　事件监控：对公有云产品和业务逻辑中的不连续事件，如云盘不可用事件、SSD硬盘复位事件等提供统一的存储、分析和展示。

　　有了上述原子化场景的数据采集，我们就可以通过UI统一展示监控数据，并根据上述三个维度设计一个以用户体验为核心的图形化页面。图形一般以时间序列为横轴，显示指标随时间的变化。对于一些统计指标，还可以通过饼图和条形图的方式展示分析比较结果。

　　本文主要介绍监控系统中的采集和数据展示。至于数据存储和报警过程，有兴趣的同学可以继续关注后续监控相关的文章。

　　关于作者

　　董磊：UCloud 技术专家。十年IT行业开发经验，目前负责UCloud混合云及监控产品的设计开发，持续专注于微服务架构、监控、DevOps等领域。