日照分析收费标准及日志分析系统调研分析-ELK-EFK

日照分析收费标准建筑日照分析工作已开展多年，但收费标准差别较大。

一、浙江某市日照分析收费标准规定较细，其收费形式分为四段。

第一段数据处理，调取现状地块建筑资料200元/幢、建筑蓝图数字化处理500元/幢。第二段建模分析，拟建建筑建模分析0.60元/m2、周边现状建模分析2000元/幢。第三段方案调整，基地无变化建筑0.3元/m2、基地无变化建筑0.3元/m2、周边现状或拟建有变化建筑1000元/幢。第四段成果提交，分析报告制作、审核、打印等5000元/项。

上述四段概括为：调取图纸建模分析方案调整打印报告。我们举一个拟建10万平米小区（12幢），其北、东、西侧共5万平方米现状建筑（10/幢）为例，按上述标准试算。

调取图纸：200元/幢x10/幢+500元/幢x12/幢=8000元

建模分析：100000m2x0.60元/m2+10幢x2000元/幢=80000元

方案调整：（100000+50000）m2x0.3元/m2=450000元

打印报告：5000元

以上合计：8000+80000+45000+5000=138000元（13.8万元）

二、广东某市日照分析报告编制收费标准：

按照建筑面积规模不同分段累计收费。

建筑面积计量单位收费标准

0－20000平方米基准价格6000元

20000－50000平方米按0.3元/平方米计费

50000－100000平方米按0.25元/平方米计费

100000－200000平方米按0.2元/平方米计费

20万以上平方米按0.1元/平方米计费

按此标准试算

（100000+50000）m2x0.2元/平方米=30000元（3万元）

三、辽宁某市日照分析收费标准：

按照13987.95元/立面

按此标准试算

（12+10）/幢x13987.95元/立面=307714元（约30万元）

四、一般地区日照分析收费标准为0.6元/平方米

按此标准试算

（100000+50000）m2x0.6元/平方米=90000元（9万元）

五、建议收费方式

由此可见同一个项目在不同地区不同单位进行日照分析，收费差别非常大。个人认为应该按照委托方用途、工程阶段、建筑规模、模型复杂度、方案调整难度、报告编制单位来综合考虑收费水平。

按用途来说分为日照纠纷维权、规划项目报批。日照纠纷维权建议按照户为单位收取，因为最终报告将以户为单位提交，收费水平按照5000元/户,再结合模型难易程度和当地经济水平进行上下百分之五十浮动。

如果是项目报批就需按其计算要求收费，比如只要求计算平面等时线，则可按照0.1元/m2，最低收费2000元。如需要立面等时线，则可按照0.3元/m2，最低收费5000元。如需要窗户日照时间，则按照0.5元/m2，最低收费8000元。一般方案调整按照0.15元/m2，最低收费5000元。多次调整或者调整难度较大可按照0.2元/m2，最低收费8000元。

按此标准试算

日照分析：（100000+50000）m2x0.3元/平方米=45000元（4.5万元）

方案调整：（100000+50000）m2x0.15元/平方米=22500元（2.25万元）

以上合计6.75万元

上述收费水平为甲级设计院，如果是乙级或者其它单位编制，应参照此收费水平酌情优惠。

所有项目报批用途的日照分析报告，即使建筑规模上百万平方米，建议总收费额不超过20万元。日志分析系统目录一.背景介绍 2二．日志系统比较 21．怎样收集系统日志并进行分析 2A.实时模式： 2B.准实时模式 22.常见的开源日志系统的比较 3A.FaceBook的Scribe 3B.Apache的Chukwa 3C.LinkedIn的Kafka 4E.总结 8三．较为成熟的日志监控分析工具 81.ELK 9A.ELK简介 9B.ELK使用场景 10C.ELK的优势 10D.ELK的缺点： 112.EFK 113.Logstash于FluentD(Fluentd)对比 11一.背景介绍许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的pv，查询等），处理这些日志需要特定的日志系统，一般而言，这些系统需要具有以下特征：（1）构建应用系统和分析系统的桥梁，并将它们之间的关联解耦；（2）支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统；（3）具有高可扩展性。即：当数据量增加时，可以通过增加节点进行水平扩展。二．日志系统比较1．怎样收集系统日志并进行分析A.实时模式：

1在打印日志的服务器上部署agent

2agent使用低耗方式将日志增量上传到计算集群

3计算集群解析日志并计算出结果，尽量分布式、负载均衡，有必要的话（比如需要关联汇聚）则采用多层架构

4计算结果写入最适合的存储（比如按时间周期分析的结果比较适合写入TimeSeries模式的存储）

5搭建一套针对存储结构的查询系统、报表系统

补充：常用的计算技术是stormB.准实时模式

1在打印日志的服务器上部署agent

2agent使用低耗方式将日志增量上传到缓冲集群

3缓冲集群将原始日志文件写入hdfs类型的存储

4用hadoop任务驱动的解析日志和计算

5计算结果写入hbase

6用hadoop系列衍生的建模和查询工具来产出报表

补充：可以用hive来帮助简化2.常见的开源日志系统的比较A.FaceBook的ScribeScribe是facebook开源的日志收集系统，在facebook内部已经得到大量的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案。特点:容错性好。当后端的存储系统crash时，scribe会将数据写到本地磁盘上，当存储系统恢复正常后，scribe将日志重新加载到存储系统中。架构：scribe的架构比较简单，主要包括三部分，分别为scribeagent，scribe和存储系统。(1)scribeagentscribeagent实际上是一个thriftclient。向scribe发送数据的唯一方法是使用thriftclient，scribe内部定义了一个thrift接口，用户使用该接口将数据发送给server。(2)scribescribe接收到thriftclient发送过来的数据，根据配置文件，将不同topic的数据发送给不同的对象。scribe提供了各种各样的store，如file，HDFS等，scribe可将数据加载到这些store中。(3)存储系统存储系统实际上就是scribe中的store，当前scribe支持非常多的store，包括file（文件），buffer（双层存储，一个主储存，一个副存储），network（另一个scribe服务器），bucket（包含多个store，通过hash的将数据存到不同store中），null(忽略数据)，thriftfile（写到一个ThriftTFileTransport文件中）和multi（把数据同时存放到不同store中）。B.Apache的Chukwachukwa是一个非常新的开源项目，由于其属于hadoop系列产品，因而使用了很多hadoop的组件（用HDFS存储，用mapreduce处理数据），它提供了很多模块以支持hadoop集群日志分析。需求：(1)灵活的，动态可控的数据源(2)高性能，高可扩展的存储系统(3)合适的框架，用于对收集到的大规模数据进行分析架构：Chukwa中主要有3种角色，分别为：adaptor，agent，collector。(1)Adaptor数据源可封装其他数据源，如file，unix命令行工具等目前可用的数据源有：hadooplogs，应用程序度量数据，系统参数数据（如linuxcpu使用流率）。(2)HDFS存储系统Chukwa采用了HDFS作为存储系统。HDFS的设计初衷是支持大文件存储和小并发高速写的应用场景，而日志系统的特点恰好相反，它需支持高并发低速率的写和大量小文件的存储。需要注意的是，直接写到HDFS上的小文件是不可见的，直到关闭文件，另外，HDFS不支持文件重新打开。(3)Collector和Agent为了克服(2)中的问题，增加了agent和collector阶段。Agent的作用：给adaptor提供各种服务，包括：启动和关闭adaptor，将数据通过HTTP传递给Collector；定期记录adaptor状态，以便crash后恢复。Collector的作用：对多个数据源发过来的数据进行合并，然后加载到HDFS中；隐藏HDFS实现的细节，如，HDFS版本更换后，只需修改collector即可。(4)Demux和achieving直接支持利用MapReduce处理数据。它内置了两个mapreduce作业，分别用于获取data和将data转化为结构化的log。存储到datastore（可以是数据库或者HDFS等）中。C.LinkedIn的KafkaKafka是2010年12月份开源的项目，采用scala语言编写，使用了多种效率优化机制，整体架构比较新颖（push/pull），更适合异构集群。设计目标：(1)数据在磁盘上的存取代价为O(1)(2)高吞吐率，在普通的服务器上每秒也能处理几十万条消息(3)分布式架构，能够对消息分区(4)支持将数据并行的加载到hadoop架构：Kafka实际上是一个消息发布订阅系统。producer向某个topic发布消息，而consumer订阅某个topic的消息，进而一旦有新的关于某个topic的消息，broker会传递给订阅它的所有consumer。在kafka中，消息是按topic组织的，而每个topic又会分为多个partition，这样便于管理数据和进行负载均衡。同时，它也使用了zookeeper进行负载均衡。Kafka中主要有三种角色，分别为producer，broker和consumer。(1)ProducerProducer的任务是向broker发送数据。Kafka提供了两种producer接口，一种是low_level接口，使用该接口会向特定的broker的某个topic下的某个partition发送数据；另一种那个是highlevel接口，该接口支持同步/异步发送数据，基于zookeeper的broker自动识别和负载均衡（基于Partitioner）。其中，基于zookeeper的broker自动识别值得一说。producer可以通过zookeeper获取可用的broker列表，也可以在zookeeper中注册listener，该listener在以下情况下会被唤醒：a．添加一个brokerb．删除一个brokerc．注册新的topicd．broker注册已存在的topic当producer得知以上时间时，可根据需要采取一定的行动。(2)BrokerBroker采取了多种策略提高数据处理效率，包括sendfile和zerocopy等技术。(3)Consumerconsumer的作用是将日志信息加载到中央存储系统上。kafka提供了两种consumer接口，一种是lowlevel的，它维护到某一个broker的连接，并且这个连接是无状态的，即，每次从broker上pull数据时，都要告诉broker数据的偏移量。另一种是high-level接口，它隐藏了broker的细节，允许consumer从broker上push数据而不必关心网络拓扑结构。更重要的是，对于大部分日志系统而言，consumer已经获取的数据信息都由broker保存，而在kafka中，由consumer自己维护所取数据信息。D.Cloudera的FlumeFlume是cloudera于2009年7月开源的日志系统。它内置的各种组件非常齐全，用户几乎不必进行任何额外开发即可使用。设计目标：(1)可靠性当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Storeonfailure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。(2)可扩展性Flume采用了三层架构，分别问agent，collector和storage，每一层均可以水平扩展。其中，所有agent和collector由master统一管理，这使得系统容易监控和维护，且master允许有多个（使用ZooKeeper进行管理和负载均衡），这就避免了单点故障问题。(3)可管理性所有agent和colletor由master统一管理，这使得系统便于维护。用户可以在master上查看各个数据源或者数据流执行情况，且可以对各个数据源配置和动态加载。Flume提供了web和shellscriptcommand两种形式对数据流进行管理。(4)功能可扩展性用户可以根据需要添加自己的agent，colletor或者storage。此外，Flume自带了很多组件，包括各种agent（file，syslog等），collector和storage（file，HDFS等）。架构：正如前面提到的，Flume采用了分层架构，由三层组成，分别为agent，collector和storage。其中，agent和collector均由两部分组成：source和sink，source是数据来源，sink是数据去向。(1)agentagent的作用是将数据源的数据发送给collector，Flume自带了很多直接可用的数据源（source）(2)collectorcollector的作用是将多个agent的数据汇总后，加载到storage中。它的source和sink与agent类似。下面例子中，agent监听TCP的5140端口接收到的数据，并发送给collector，由collector将数据加载到HDFS上。一个更复杂的例子如下：有6个agent，3个collector，所有collector均将数据导入HDFS中。agentA，B将数据发送给collectorA，agentC，D将数据发送给collectorB，agentC，D将数据发送给collectorB。同时，为每个agent添加end-to-end可靠性保障（Flume的三种可靠性保障分别由agentE2EChain,agentDFOChain,andagentBEChain实现），如，当collectorA出现故障时，agentA和agentB会将数据分别发给collectorB和collectorC。此外，使用autoE2EChain，当某个collector出现故障时，Flume会自动探测一个可用collector，并将数据定向到这个新的可用collector上。(3)storagestorage是存储系统，可以是一个普通file，也可以是HDFS，HIVE，HBase等。E.总结根据这四个系统的架构设计，可以总结出典型的日志系统需具备三个基本组件，分别为agent（封装数据源，将数据源中的数据发送给collector），collector（接收多个agent的数据，并进行汇总后导入后端的store中），store（中央存储系统，应该具有可扩展性和可靠性，应该支持当前非常流行的HDFS）。下面表格对比了这四个系统：ScribeChukwaKafkaFlume公司FacebookApache/yahooLinkedInCloudera开源时间2008/102009/112010/122009/7实现语言C/C++JAVASCALAJAVA框架Push/pushPush/pushPush/pullPush/push容错性Collector和store之间有容错机制，而agent和collector之间的容错需要客户自己实现Agent定期记录已发送给collector的数据偏移量，一旦出现故障后，可根据漂移量继续发送数据Agent可用通过collector自动识别机制获取可用的collector，store自己保存以获取的数据的偏移量，一旦collector出故障后，可根据偏移量获取数据Agent和collector，collector和store之间均有容错机制，且提供了三种级别的可靠保证负载均衡无无使用zookeeper使用zookeeper可扩张性好好好好AgentThriftclient，需要自己实现自带一些agent，如获取hadooplog的agent用户需根据Kafka提供的low-level和high-levelAPI自行实现提供了各种非常丰富的agentCollector实际上是一个thriftserver--使用了sendfile，zero-copy等技术提高性能系统提供了很多collector，直接可以使用Store直接支持HDFS直接支持HDFS直接支持HDFS直接支持HDFS总体评价设计简单，易于使用，但容错和负载均衡方面不够好，且资料较少属于hadoop系列产品，直接支持hadoop，目前版本升级较快，但还有待完善设计构架（push/pull）非常巧妙，适合异构集群，但产品叫新，其稳定性有待验证非常优秀三．较为成熟的日志监控分析工具1.ELKA.ELK简介ELK在服务器运维界应该是运用的非常成熟了，很多成熟的大型项目都使用ELK来作为前端日志监控、分析的工具。前端日志与后端日志不同，具有很强的自定义特性，不像后端的接口日志、服务器日志格式比较固定，大部分成熟的后端框架都有非常完善的日志系统，借助一些分析框架，就可以实现日志的监控与分析，这也是运维工作的一部分。ELK实际上是三个工具的集合：E：Elasticsearch(弹性搜索)L：LogstashK：Kibana这三个工具（框架）各司其职，最终形成一整套的监控架构。ElasticsearchElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。我们使用Elasticsearch来完成日志的检索、分析工作。LogstashLogstash是一个用于管理日志和事件的工具，可以用它去收集日志、转换日志、解析日志并将他们作为数据提供给其它模块调用，例如搜索、存储等。我们使用Logstash来完成日志的解析、存储工作。KibanaKibana是一个优秀的前端日志展示框架，它可以非常详细的将日志转化为各种图表，为用户提供强大的数据可视化支持。我们使用Kibana来进行日志数据的展示工作。B.ELK使用场景现在已经有非常多的公司在使用这套架构了，例如Sina、饿了么、携程，这些公司都是这方面的先驱。同时，这套东西虽然是后端的，但是『他山之石，可以攻玉』，我们将这套架构借用到前端，可以使用前端日志的分析工作，同样是非常方便的。这里我举一些常用的使用场景。业务数据分析通过客户端的数据采集系统，可以将一些业务流程的关键步骤、信息采集到后端，进行业务流程的分析。错误日志分析类似Bugly，将错误日志上报后，可以在后端进行错误汇总、分类展示，进行错误日志的分析。数据预警利用ELK，可以很方便的对监控字段建立起预警机制，在错误大规模爆发前进行预警。C.ELK的优势a.强大的搜索这是elasticsearch的最强大的功能，他可以以分布式搜索的方式快速检索，而且支持DSL的语法来进行搜索，简单的说，就是通过类似配置的语言，快速筛选数据。b.强大的展示这是Kibana的最强大的功能，他可以展示非常详细的图表信息，而且可以定制展示内容，将数据可视化发挥的淋漓尽致。所以，借助ELK的这两大优势，我们可以让前端日志的分析与监控展现出强大的优势。D.ELK的缺点：1、三个独立的系统，没有统一的部署、管理工具，用户需要分别部署及管理这三套系统2、复杂业务下权限的分组管理，企业肯定希望每个业务部分看自身的，但又存在矛盾点，企业想看汇总情况。3、安全漏洞，之前乌云网站曾爆出Elasticsearch存在严重的安全漏洞。4、不进行深度开发的话，数据挖掘能力弱2.EFK市场上另外一个非常好的数据收集解决方案即是Fluentd，它也支持Elasticsearch作为数据收集的目的地。所以运用相同的数据存储和前端解决方案，便形成了EFK.许多人选择用Fluentd代替logtash。3.Logstash于FluentD(Fluentd)对比二者都有许多可用插件，被积极的维护着。技术上：Lostash：有良好的并行性支持，jvm有很好的Grok支持FlentD：缺少支持windows平台传输上：两者同时提供向一个非常必要的的选项，即向一个完全成熟的实例读送日志信息的部署轻量级组件。安装FluentdLogstash安装过程Repository(apt/yum)or

CompressedArchive占磁盘大小165.3M154.9