Return-Path: X-Original-To: apmail-samza-dev-archive@minotaur.apache.org Delivered-To: apmail-samza-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E1B3A18939 for ; Mon, 16 Nov 2015 18:02:29 +0000 (UTC) Received: (qmail 45039 invoked by uid 500); 16 Nov 2015 18:02:29 -0000 Delivered-To: apmail-samza-dev-archive@samza.apache.org Received: (qmail 44977 invoked by uid 500); 16 Nov 2015 18:02:29 -0000 Mailing-List: contact dev-help@samza.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@samza.apache.org Delivered-To: mailing list dev@samza.apache.org Received: (qmail 44964 invoked by uid 99); 16 Nov 2015 18:02:29 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2015 18:02:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id AF50FC05AD for ; Mon, 16 Nov 2015 18:02:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.149 X-Spam-Level: *** X-Spam-Status: No, score=3.149 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id tdGcT4O8cuIw for ; Mon, 16 Nov 2015 18:02:27 +0000 (UTC) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 8ADE720384 for ; Mon, 16 Nov 2015 18:02:27 +0000 (UTC) Received: by iouu10 with SMTP id u10so161810947iou.0 for ; Mon, 16 Nov 2015 10:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rN3ThOu2PyVatWaGzxMK/Xv3pWQZYGUdXH4ai5NET90=; b=Kptp5CmT5UcVLqc0SYB36S79Bm6AsNY2daub48qJjTj+L6nH40KJx0G6HQxPY2MqiF pGrlBluL1xLMGxynXREO/89Vk8p51Xbp2Gj/xXaO0BpyDdPZhsyHPPJbqLt1Z81NLYpD ujCEtdaOlSnN8BMVB1G7T+nnpya2j+33G0k+xB7XuZ9xRHLXwpTWY0TEzfasABlJ8fM6 LftBtUDCPfIuZNeNjUO3IC1s0rFNcrg9pxxyssiEDj2/WqWneua+s60HToaEb5A5qYfp dFVq64ldiKdsCAA4Cg7e1zqmkAOI3qSSeqNu1FAxigAgrmZ2wybNST8UWFVF9dNL5ugR 9oHw== MIME-Version: 1.0 X-Received: by 10.107.184.9 with SMTP id i9mr21270154iof.4.1447696946733; Mon, 16 Nov 2015 10:02:26 -0800 (PST) Received: by 10.107.20.145 with HTTP; Mon, 16 Nov 2015 10:02:26 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Nov 2015 10:02:26 -0800 Message-ID: Subject: Re: Monitoring consumer lag From: Jagadish Venkatraman To: dev@samza.apache.org Content-Type: multipart/alternative; boundary=94eb2c06d10040a7ea0524ac36c7 --94eb2c06d10040a7ea0524ac36c7 Content-Type: text/plain; charset=UTF-8 The following metrics are reported via JMX. 1. Samza exposes a per-partition metric called "$topicname-$partition_name- messages-behind-high-watermark". This measures the number of messages behind the high watermark of your consumer. Ideally, at steady state, you would expect this metric to be zero (with occasional spikes depending on your traffic). 2. For your second usecase, "$topicname-$partition_name-bytes-read", ""$topicname-$partition_name-messages-read" are interesting. You can query these metrics and get alerted based on them. On Mon, Nov 16, 2015 at 9:16 AM, Michael Ravits wrote: > Hi, > > I'd like to monitor consumer's lag. > Found this tool https://github.com/linkedin/Burrow. > But now realized that Samza is using it's own checkpointing mechanism. > > So question is what's the best way to monitor whether and how much the > consumer is lagging? > > On a related subject, I'd also like to monitor throughput per topic in > terms of messages per second and bytes per second. Should I query brokers > periodically, or maybe there is a better way? > > Thanks, > Michael > -- Jagadish V, Graduate Student, Department of Computer Science, Stanford University --94eb2c06d10040a7ea0524ac36c7--