我们已经使用grep/sed/awk等Linux脚本工具查找日志中的问题，为什么还需要日志易？

一些公司的运维工程师在运维故障发生后，登录各台服务器，使用grep/sed/awk等Linux脚本工具去日志里查找故障原因，排障时间长，未必能及时找到故障根源。日志易快速接收原始日志，统一管理并建立索引，能在几秒钟内返回搜索分析结果，帮助及时定位故障原因。而且日志易可以设置告警监控，在故障发生或即将发生的时候就发出告警。另外，日志易的仪表盘等功能可以让运维工程师随时主动通过日志查看系统状况，对系统情况了如指掌，避免事后救火的被动。

用户需要一个统一的日志处理系统吗？

一些公司的日志分散在各台服务器上，每次查找日志都要登录到各台服务器，效率低下。使用日志易统一管理日志，在一个界面上就可以查看所有日志，大大提高运维效率。

黑客在入侵服务器或网络设备时，往往会删掉日志，抹除作案证据。使用日志易统一上传、管理日志，可及时发现入侵行为，监控告警，也可以长期保存日志，方便事后安全审计。

一些公司的日志由各业务部门分别处理，导致了日志数据及分析结果的碎片化。日志是一家公司运营情况的真实数据，不同业务部门的日志往往互相关联。在公司层面统一处理、分析日志，可以把不同来源的日志对照关联分析，去除噪音，反应真实情况。LinkedIn（领英）的架构师写的这篇文章"深度解析LinkedIn大数据平台"，详细阐述了建立统一日志处理平台对一家公司的重大价值及LinkedIn在这方面的具体实践，非常值得参考。

我们已经使用关系型数据库处理日志，还需要日志易吗？

使用关系型数据库处理日志有两个问题：

  1. 关系型数据库的表格式（Schema）是固定的，而不同来源的日志格式多种多样，当增加新的日志格式时，改变数据库Schema会很困难；
  2. 关系型数据库是为多次读写的小数据量设计的，而日志的处理特征是一次写、多次读，量非常大，关系型数据库不适合这样的大数据场景。

对于日志这样的大数据，文档型数据库（Document Database，NoSQL的一种）是更合适的选择。日志易采用索引文件处理、存储日志，可对各种格式的日志进行全文索引，非常灵活方便。日志易就是一个日志的搜索引擎。

我们已经使用Hadoop处理日志，还需要日志易吗？

Hadoop是个开发框架，用户需要开发Hadoop程序处理日志，使用门槛较高，优秀的Hadoop开发工程师不容易招到；而且Hadoop是批处理，实时性较差。不少使用Hadoop处理日志的公司通常是每天晚上处理当天的日志，第二天出统计报表。有些公司做得好些，每隔几小时处理一次日志，但也只能看到几小时前的日志分析。日志易采用流式实时处理框架，用户可看到10秒钟之前的日志；而且日志易是拿来即用的Turn Key Solution，不需要用户做任何开发。

一些用户使用Hadoop框架下的Hive或Pig查询日志，延时可能达到几十分钟。使用日志易查询、分析日志，延时只有几秒。日志易使用了性能比Hadoop快10倍的Spark Streaming架构。Hadoop的发明人Doug Cutting也认为Hadoop未来会被Spark取代。

一些用户使用HBase来存储、处理日志，HBase不支持二级索引，一旦确定好RowKey（一级索引）后，对非RowKey的关键字搜索基本都是全表扫描，实时性比搜索引擎要差；而日志易这样的日志搜索引擎可以针对用户设置的多个关键字自动建立索引，满足关键字实时搜索和统计分析的需求。采用HBase，要求日志源转换成结构化数据；而日志易支持所有日志源，用户可以自己配置解析规则，相比HBase，日志易可以减少用户在转换日志方面的工作量。

日志易相比Spark SQL有什么优势？

Spark SQL是Spark框架下对结构化数据进行SQL语法查询的模块，并不支持全文检索，而日志是非结构化数据，使用日志易这样的搜索引擎对日志进行全文检索是更加方便、高效的方式。

日志易与开源系统ELK相比，有什么优势？

ELK指Elasticsearch/Logstash/Kibana这3个开源软件的组合，可用于日志搜索。

Elasticsearch是基于开源搜索库Lucene开发的通用开源搜索引擎，在不少垂直搜索领域应用。Elasticsearch用于日志搜索这种对实时要求比较高的场景时，需要做性能调优，甚至定制化开发，才能较好地满足大数据量、低延时的要求。一些日志关联分析的功能Elasticsearch也没有，需要做开发。

Logstash是系统管理员Jordan Sissel用脚本语言Ruby开发的日志关键字段提取及处理工具，目标用户是系统管理员，需要做大量的配置，而且开源软件需要花费时间维护，综合成本不低。

Kibana是基于Elasticsearch的Web展示界面，功能比较少，许多Elasticsearch提供的功能没有实现，需要用户做不少开发才能充分应用Elasticsearch的重要功能。日志易实现了事件计数统计、时间分段统计、数值分段统计、时间直方图统计、数值直方图统计、字段值分类统计、字段数值统计、累计百分比统计等功能，功能比Kibana丰富得多。

使用ELK有以下问题：

  1. 运维管理不方便。ELK是三个独立的系统，没有统一的部署、管理工具，用户需要分别部署及管理这三套系统。日志易是一套成熟的系统，提供了统一的部署、管理、监控功能，非常方便运维管理。
  2. 没有告警功能。日志易提供了邮件、短信告警功能。
  3. 没有用户认证及权限管理。日志易提供了丰富的用户认证及权限管理，用户可分为管理员及普通用户，可对日志分组，不同用户只能查看不同分组的日志。
  4. 统计、分析功能有限。除了丰富的统计功能外，日志易还实现了不同来源日志的关联分析，支持日志的事务分析。
  5. Elasticsearch存在严重的安全漏洞，没经验的用户很可能中招，被黑客入侵。在乌云网站上，关于用户使用Elasticsearch不慎导致的安全漏洞非常多。

在日志来源多样、日志量大、延时要求短、功能要求多、希望拿来就用（不需要二次开发）的情况下，日志易是您的最好选择。

日志易与Splunk相比有什么优势？

Splunk是美国做日志搜索分析的工具软件，但有以下不足：

  1. Splunk使用私有的Search Processing Language (SPL) 做日志搜索分析，用户需要使用SPL写脚本程序，使用门槛比较高；
  2. Splunk在日志检索阶段抽取日志里的关键字段，检索速度慢，性能较差；
  3. Splunk价格较贵。

全球最具权威的IT研究与顾问咨询公司Gartner在2014年7月18日的Splunk市场研究报告《Vendor Insight: Splunk, Separating Hype From Reality》里提到用户对Splunk的抱怨：

  • "Splunk does no parsing of data before it comes into the system, providing for the most flexibility to the user, but not always the most highly performing system." "Gartner clients do complain regularly about performance as the system grows."

  • "Splunk Enterprise is priced based on the volume of data coming into the product per day. Linking licensing fees to data volume is the most common complaint of Gartner clients and is limiting the use cases for Splunk within many organizations."

日志易相比Splunk的优势：

  1. 使用简单的查询语法，通过用户图形界面实现各种统计分析功能，简单易用，用户上手快；
  2. 日志进入系统后，就抽取关键字段并做索引，检索时直接查询这些关键字段，速度非常快；
  3. 价格比Splunk便宜；
  4. 日志易在北京、深圳有研发团队，可结合国内用户的使用场景，开发完全满足国内用户需求的产品。

日志易在 IT Operation Analytics（ITOA）里的定位是什么？

ITOA把大数据技术应用于IT运维，让运维工程师能够通过数据分析提升IT运维水平，主要用于可用性监控、应用性能监控、故障根源分析、安全审计等方面。全球最具权威的IT研究与顾问咨询公司Gartner估计，到2017年，15%的大企业会积极使用ITOA；而在2014年，这一数字只有5%。

ITOA的数据来源有以下四个方面：

  1. 机器数据（Machine Data）：是IT系统自己产生的数据，包括客户端、服务器、网络设备、安全设备、应用程序、传感器产生的日志，及 SNMP、WMI 等时间序列事件数据，这些数据都带有时间戳。机器数据无所不在，反映了IT系统内在的真实状况，但不同系统产生的机器数据的质量、可用性、完整性可能差别较大。
  2. 通信数据（Wire Data）：是系统之间2~7层网络通信协议的数据，可通过网络端口镜像流量，进行深度包检测 DPI（Deep Packet Inspection）、包头取样 Netflow 等技术分析。一个10Gbps端口一天产生的数据可达100TB，包含的信息非常多，但一些性能、安全、业务分析的数据未必通过网络传输，从而无法获得。
  3. 代理数据（Agent Data）：是在 .NET 或 Java 字节码里插入代理程序，从字节码里统计函数调用、堆栈使用等信息，从而进行代码级别的监控。但要求改变代码并且会增加程序执行的开销，降低性能。
  4. 探针数据（Probe Data），又叫合成数据（Synthetic Data）：是模拟用户请求，对系统进行检测获得的数据，如 ICMP ping、HTTP GET等，能够从不同地点模拟客户端发起，进行包括网络和服务器的端到端全路径检测，及时发现问题。但这种检测并不能发现系统为什么性能下降或者出错，而且这种检测是基于取样，并不是真实用户度量（Real User Measurement）。

美国某ITOA公司的用户调研发现，使用这四种不同数据来源的比例为：Machine Data 86%，Wire Data 93%，Agent Data 47%，Probe Data 72%。

这四种数据来源各有利弊，结合在一起使用，效果最好。日志易专注于机器数据的处理，也可以对接网络抓包工具，处理网络通信数据。把日志易与其他ITOA工具结合使用，将大大提升IT运维能力。

日志易与应用性能管理 APM 及网络性能管理 NPM 有什么不同？

应用性能管理系统 APM (Application Performance Management）与网络性能管理系统 NPM（Network Performance Management）都属于ITOA（IT Operation Analytics）。

APM 监控特定软件系统的性能和可用性，传统的 APM 通过在代码嵌入代理获取代理数据（Agent Data），或通过探针数据（Probe Data），监控和检测异常来分析应用程序的性能；NPM 通过网络通信数据（Wire Data）监控系统性能。如前面所述，这些数据来源各有利弊。

日志的价值在于它们无处不在：应用程序，操作系统，数据库，甚至硬件都生成日志。日志易不需要在这些系统嵌入插件，只需要采集这些系统的日志就能做分析，非常方便。APM 或 NPM 系统也需要依赖日志分析获得更全面的系统信息，日志易可作为 APM 或 NPM 系统的补充，提供更全面、准确的应用性能监控及网络性能监控。

为什么用户不自主开发日志管理系统？

互联网、金融、电信、能源及其他行业的企业都明白，公司需要专注于自己的业务。日志管理分析是基础工具，拿来就用是最省时间和资源的作法。对于已经自主开发了内部日志管理系统的公司，随着业务发展日志管理会越来越复杂，自主开发、维护日志管理分析工具的成本将会超过直接使用日志易的成本。

用户能上传什么类型的日志？如何上传？

只要是文本日志都可以上传。日志易可以接收、处理各种文本日志，包括来自Linux的Syslog/Apache/Nginx/MySQL/Log4j等日志都可以处理。

日志可以通过Syslog流式上传，也可以通过HTTP POST批量上传。任何可以上网的设备都可以转发日志，对于无法直连日志易的设备，可以设置一个中央代理来转发日志到日志易。

我通过文件上传日志后，为什么搜不到上传的日志？？

用户通过文件上传的日志，可能是很久以前存下来的日志，日志的时间戳比较久远。在搜索这种日志的时候，需要把搜索框旁边的时间范围设置成足够大，覆盖上传日志的时间戳，这样就可以搜索到上传的日志了。

日志易支持什么浏览器？

支持所有常用浏览器，包括Chrome，Firefox，Safari，IE9或以上版本，360浏览器，搜狗浏览器等。