共 4 篇相关文章
作者结合两年生产实践，分享了对Facebook开源日志系统Scribe的应用总结。Scribe以精简稳定著称，作者团队在线上运行超过两年，未曾遭遇其自身进程崩溃。 文章核心聚焦于生产环境中Scribe的关键运维实践。针对Master节点宕机，标准配置是Primary接Secondary文件，故障时日志本地缓存，恢复后自动补发，并可通过一行脚本监控积压。为防止Scribe进程意外阻塞业务，建议采用异步线程写日志。而最棘手的情况是网络拥塞导致日志追送困难，作者提到一项压缩传输的改造尝试。文章最后将Scribe与LinkedIn开源的Kafka进行对比：Scribe如同“激流勇进”的冲锋舟，简单可靠；Kafka则似“航空母舰”，以集群和去中心化设计，对单点故障的容忍度更高。作者认为，对于中心化的日志收集场景，两者各有适用之处。
这篇讲的是谷歌App Engine这个PaaS平台，作者从实际选型的角度出发，深入剖析了它的核心设计思路与典型应用场景。 文章没有泛泛而谈，而是紧扣App Engine作为“无服务器”先驱的特点展开。重点解释了它的沙箱隔离机制、自动扩缩容策略，以及背后对开发者“只需专注代码”的承诺是如何通过底层架构实现的。文中还将它与Heroku、AWS Elastic Beanstalk等主流PaaS进行了横向对比，指出了关键差异：例如App Engine与Google Cloud数据服务的深度集成、特定语言运行时的限制，以及在不同计费模型下的成本考量。 最终，文章给出的结论很明确：App Engine特别适合那些希望快速迭代、流量波动明显且技术栈与之匹配的应用。对于追求完全控制或需要深度定制基础设施的团队，它可能并非首选。整篇分析立足于技术细节，为读者的选型决策提供了扎实的参考依据。
这篇讲的是如何用Facebook开源的分布式日志系统Scribe，与Hadoop生态中的数据仓库工具Hive搭建一套高效的用户行为分析方案。Scribe在官方示例中能支撑每秒高达200万条日志的高并发采集，而Hive则能将结构化日志文件映射为表，并通过熟悉的SQL查询转换为MapReduce任务执行，非常适合对海量日志进行灵活分析。 作者54chen在文中分享了自己实践Scribe和Hive的经验手记，核心在于解决如何让两者协同工作。具体步骤上，文章从创建与Scribe日志格式相匹配的Hive表开始，引导读者逐步搭建起从日志收集到分析查询的完整流程。这套方案的价值在于，它让企业可以充分利用Scribe在高吞吐日志采集上的优势，并结合Hive强大的数据仓库查询能力，从而低成本、高效率地完成用户行为等大规模日志数据的分析工作。
这篇讲的是如何用Facebook开源的Scribe搭建分布式日志系统。作者从实际需求出发，介绍了Scribe的核心优势：它通过thrift协议传输日志，能轻松整合不同语言的项目，实现从本地到远程的统一日志收集。在性能上，Scribe示例配置的并发量可达每秒200万条消息，对于绝大多数应用来说，即便是最基础的配置也能保证远程日志收集的可靠性。如果遇到更高压力，还可以通过主从架构自动同步日志到本地，进一步提升稳定性。文章接下来会具体演示Scribe的安装与配置过程。
