「JavaAPI监控」java监控平台

今天给各位分享JavaAPI监控的知识，其中也会对java监控平台进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Java的核心技术有哪些？
• 2、用Java编程来实现CPU和Memory监控器并将数据持久化，保存在文件中。急用
• 3、Java类应用监控应该监控哪些
• 4、Java怎么获取zabbix监控到的信息？？
• 5、Java 如何监控文件目录的变化

Java的核心技术有哪些？

java学习中的13个核心技术分享给你

1. JDBC(Java Database Connectivity)：

JDBC API为访问不同的数据库提供了一种统一的途径象ODBC一样，JDBC对开发者屏蔽了一些细节问题，另外JDCB对数据库的访问也具有平台无关性。

2. JNDI(Java Name and Directory Interface)：

JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP，本地文件系统或应用服务器中的对象。

3. EJB(Enterprise JavaBean):

J2EE技术之所以赢得媒体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑，由此很显著地简化了具有可伸缩性和高度复杂的企业级应用的开发。EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务，例如目录服务、事务管理、安全性、资源缓冲池以及容错性。但这里值得注意的是EJB并不是实现J2EE的唯一途径。正是由于J2EE的开放性使得有的厂商能够以一种和EJB平行的方式来达到同样的目的。

4. RMI(Remote Method Invoke):

正如其名字所表示的那样，RMI协议调用远程对象上方法。它使用了序列化方式在客户端和服务器端传递数据。RMI是一种被EJB使用的更底层的协议。

5. Java IDL/CORBA:

在Java IDL的支持下开发人员可以将Java和CORBA集成在一起。他们可以创建Java对象并使之可在CORBA ORB中展开,或者他们还可以创建Java类并作为和其它ORB一起展开的CORBA对象的客户。后一种方法提供了另外一种途径通过它Java可以被用于将你的新的应用和旧的系统相集成。

6. JSP(Java Server Pages):

JSP页面由HTML代码和嵌入其中的Java代码所组成。服务器在页面被客户端所请求以后对这些Java代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。

7. Java Servlet:

Servlet是一种小型的Java程序，它扩展了Web服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI Perl脚本很相似。Servlet提供的功能大多与JSP类似，不过实现的方式不同。JSP通常是大多数HTML代码中嵌入少量的Java代码，而servlets全部由Java写成并且生成HTML。

8. XML(Extensible Markup Language):

XML是一种可以用来定义其它标记语言的语言。它被用来在不同的商务过程中共享数据。

XML的发展和Java是相互独立的，但是它和Java具有的相同目标正是平台独立性。通过将Java和XML的组合，您可以得到一个完美的具有平台独立性的解决方案。

9. JMS(Java Message Service):

MS是用于和面向消息的中间件相互通信的应用程序接口(API)。它既支持点对点的域，有支持发布/订阅(publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。

10. JTA(Java Transaction Architecture):

JTA定义了一种标准的API，应用系统由此可以访问各种事务监控。

11. JTS(Java Transaction Service):

JTS是CORBA OTS事务监控的基本的实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持Java Transaction API (JTA)规范，并且在较底层实现OMG OTS specification的Java映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。

12. JavaMail:

JavaMail是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器，也支持IMAP服务器。

13. JAF(JavaBeans Activation Framework):

JavaMail利用JAF来处理MIME编码的邮件附件。MIME的字节流可以被转换成Java对象或者转换自Java对象。大多数应用都可以不需要直接使用JAF。

用Java编程来实现CPU和Memory监控器并将数据持久化，保存在文件中。急用

众所周知，java在处理数据量比较大的时候，加载到内存必然会导致内存溢出，而在一些数据处理中我们不得不去处理海量数据，在做数据处理中，我们常见的手段是分解，压缩，并行，临时文件等方法;例如，我们要将数据库(不论是什么数据库)的数据导出到一个文件，一般是Excel或文本格式的CSV;对于Excel来讲，对于POI和JXL的接口，你很多时候没有法去控制内存什么时候向磁盘写入，很恶心，而且这些API在内存构造的对象大小将比数据原有的大小要大很多倍数，所以你不得不去拆分Excel，还好，POI开始意识到这个问题，在3.8.4的版本后，开始提供cache的行数，提供了SXSSFWorkbook的接口，可以设置在内存中的行数，不过可惜的是，他当你超过这个行数，每添加一行，它就将相对行数前面的一行写入磁盘(如你设置2000行的话，当你写第20001行的时候，他会将第一行写入磁盘)，其实这个时候他些的临时文件，以至于不消耗内存，不过这样你会发现，刷磁盘的频率会非常高，我们的确不想这样，因为我们想让他达到一个范围一次性将数据刷如磁盘，比如一次刷1M之类的做法，可惜现在还没有这种API，很痛苦，我自己做过测试，通过写小的Excel比使用目前提供刷磁盘的API来写大文件，效率要高一些，而且这样如果访问的人稍微多一些磁盘IO可能会扛不住，因为IO资源是非常有限的，所以还是拆文件才是上策;而当我们写CSV，也就是文本类型的文件，我们很多时候是可以自己控制的，不过你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式写入即可被CSV识别出来;如何写入呢？下面来说说。。。在处理数据层面，如从数据库中读取数据，生成本地文件，写代码为了方便，我们未必要1M怎么来处理，这个交给底层的驱动程序去拆分，对于我们的程序来讲我们认为它是连续写即可;我们比如想将一个1000W数据的数据库表，导出到文件;此时，你要么进行分页，oracle当然用三层包装即可，mysql用limit，不过分页每次都会新的查询，而且随着翻页，会越来越慢，其实我们想拿到一个句柄，然后向下游动，编译一部分数据(如10000行)将写文件一次(写文件细节不多说了，这个是最基本的)，需要注意的时候每次buffer的数据，在用outputstream写入的时候，最好flush一下，将缓冲区清空下;接下来，执行一个没有where条件的SQL，会不会将内存撑爆？是的，这个问题我们值得去思考下，通过API发现可以对SQL进行一些操作，例如，通过：PreparedStatementstatement=connection.prepareStatement(sql)，这是默认得到的预编译，还可以通过设置：PreparedStatementstatement=connection.prepareStatement(sql，ResultSet.TYPE_FORWARD_ONLY，ResultSet.CONCUR_READ_ONLY);来设置游标的方式，以至于游标不是将数据直接cache到本地内存，然后通过设置statement.setFetchSize(200);设置游标每次遍历的大小;OK，这个其实我用过，oracle用了和没用没区别，因为oracle的jdbcAPI默认就是不会将数据cache到java的内存中的，而mysql里头设置根本无效，我上面说了一堆废话，呵呵，我只是想说，java提供的标准API也未必有效，很多时候要看厂商的实现机制，还有这个设置是很多网上说有效的，但是这纯属抄袭;对于oracle上面说了不用关心，他本身就不是cache到内存，所以java内存不会导致什么问题，如果是mysql，首先必须使用5以上的版本，然后在连接参数上加上useCursorFetch=true这个参数，至于游标大小可以通过连接参数上加上：defaultFetchSize=1000来设置，例如：jdbc：mysql：//xxx.xxx.xxx.xxx：3306/abc？zeroDateTimeconvertToNulluseCursorFetch=truedefaultFetchSize=1000上次被这个问题纠结了很久(mysql的数据老导致程序内存膨胀，并行2个直接系统就宕了)，还去看了很多源码才发现奇迹竟然在这里，最后经过mysql文档的确认，然后进行测试，并行多个，而且数据量都是500W以上的，都不会导致内存膨胀，GC一切正常，这个问题终于完结了。我们再聊聊其他的，数据拆分和合并，当数据文件多的时候我们想合并，当文件太大想要拆分，合并和拆分的过程也会遇到类似的问题，还好，这个在我们可控制的范围内，如果文件中的数据最终是可以组织的，那么在拆分和合并的时候，此时就不要按照数据逻辑行数来做了，因为行数最终你需要解释数据本身来判定，但是只是做拆分是没有必要的，你需要的是做二进制处理，在这个二进制处理过程，你要注意了，和平时read文件不要使用一样的方式，平时大多对一个文件读取只是用一次read操作，如果对于大文件内存肯定直接挂掉了，不用多说，你此时因该每次读取一个可控范围的数据，read方法提供了重载的offset和length的范围，这个在循环过程中自己可以计算出来，写入大文件和上面一样，不要读取到一定程序就要通过写入流flush到磁盘;其实对于小数据量的处理在现代的NIO技术的中也有用到，例如多个终端同时请求一个大文件下载，例如视频下载吧，在常规的情况下，如果用java的容器来处理，一般会发生两种情况：其一为内存溢出，因为每个请求都要加载一个文件大小的内存甚至于，因为java包装的时候会产生很多其他的内存开销，如果使用二进制会产生得少一些，而且在经过输入输出流的过程中还会经历几次内存拷贝，当然如果有你类似nginx之类的中间件，那么你可以通过send_file模式发送出去，但是如果你要用程序来处理的时候，内存除非你足够大，但是java内存再大也会有GC的时候，如果你内存真的很大，GC的时候死定了，当然这个地方也可以考虑自己通过直接内存的调用和释放来实现，不过要求剩余的物理内存也足够大才行，那么足够大是多大呢？这个不好说，要看文件本身的大小和访问的频率;其二为假如内存足够大，无限制大，那么此时的限制就是线程，传统的IO模型是线程是一个请求一个线程，这个线程从主线程从线程池中分配后，就开始工作，经过你的Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等，其实整个过程线程都是被挂住的，所以这部分资源非常有限，而且如果是大文件操作是属于IO密集型的操作，大量的CPU时间是空余的，方法最直接当然是增加线程数来控制，当然内存足够大也有足够的空间来申请线程池，不过一般来讲一个进程的线程池一般会受到限制也不建议太多的，而在有限的系统资源下，要提高性能，我们开始有了newIO技术，也就是NIO技术，新版的里面又有了AIO技术，NIO只能算是异步IO，但是在中间读写过程仍然是阻塞的(也就是在真正的读写过程，但是不会去关心中途的响应)，还未做到真正的异步IO，在监听connect的时候他是不需要很多线程参与的，有单独的线程去处理，连接也又传统的socket变成了selector，对于不需要进行数据处理的是无需分配线程处理的;而AIO通过了一种所谓的回调注册来完成，当然还需要OS的支持，当会掉的时候会去分配线程，目前还不是很成熟，性能最多和NIO吃平，不过随着技术发展，AIO必然会超越NIO，目前谷歌V8虚拟机引擎所驱动的node.js就是类似的模式，有关这种技术不是本文的说明重点;将上面两者结合起来就是要解决大文件，还要并行度，最土的方法是将文件每次请求的大小降低到一定程度，如8K(这个大小是经过测试后网络传输较为适宜的大小，本地读取文件并不需要这么小)，如果再做深入一些，可以做一定程度的cache，将多个请求的一样的文件，cache在内存或分布式缓存中，你不用将整个文件cache在内存中，将近期使用的cache几秒左右即可，或你可以采用一些热点的算法来配合;类似迅雷下载的断点传送中(不过迅雷的网络协议不太一样)，它在处理下载数据的时候未必是连续的，只要最终能合并即可，在服务器端可以反过来，谁正好需要这块的数据，就给它就可以;才用NIO后，可以支持很大的连接和并发，本地通过NIO做socket连接测试，100个终端同时请求一个线程的服务器，正常的WEB应用是第一个文件没有发送完成，第二个请求要么等待，要么超时，要么直接拒绝得不到连接，改成NIO后此时100个请求都能连接上服务器端，服务端只需要1个线程来处理数据就可以，将很多数据传递给这些连接请求资源，每次读取一部分数据传递出去，不过可以计算的是，在总体长连接传输过程中总体效率并不会提升，只是相对相应和所开销的内存得到量化控制，这就是技术的魅力，也许不要太多的算法，不过你得懂他。类似的数据处理还有很多，有些时候还会将就效率问题，比如在HBase的文件拆分和合并过程中，要不影响线上业务是比较难的事情，很多问题值得我们去研究场景，因为不同的场景有不同的方法去解决，但是大同小异，明白思想和方法，明白内存和体系架构，明白你所面临的是沈阳的场景，只是细节上改变可以带来惊人的效果。

Java类应用监控应该监控哪些

当有问题出现时，许多开发人员可能会比较盲目的用这些工具来试探性定位问题，而大多数情况下，这种试探会无功而返。因为这些分析工具主要是侧重Java单方面的分析，比如该系统调用第三方API，如果第三方API有问题，是无法监控到的。还有像文件、DB资源的访问也是是无法监控到的。

除了JAVA自带的监控工具外，我们尝试了第三方的监控工具透视宝，功能相对全面，且易操作。

在功能方面，透视宝都包括：查看执行最慢的10个元素，包括元素执行次数、持续时长和占用时长百分比；查看HTTP请求参数，包括请求的响应状态、链接页面、具体的请求参数及返回结果；查看代码执行堆栈的详细树状信息，包括每个方法的计算时间、总耗时和被调用的次数，您能直接看到特殊标识的最慢方法；查看涉及SQL语句的总耗时排序，包括SQL执行总耗时、执行次数和具体的查询语句；第三方API调用。

Java怎么获取zabbix监控到的信息？？

第一种方法：通过API进行数据交互，比较繁琐。

Zabbix使用Json格式的API，官方文档在这里：网页链接

使用Java通过HTTP的GET和POST获取信息。

第二种方法：通过数据库直接交互。速度更快。

但也需要看上面的文档。API就相当于数据库了。

这里需要的就是通过Java连接Zabbix数据库，通过视图等方式直接读取信息。

Java 如何监控文件目录的变化

JavaSE 1.7提供了相关的API，去监视文件或者文件夹的变动，主要的API都在java.nio.file下面，其大概流程如下：

package org.xdemo.superutil.j2se.filewatch;

import static java.nio.file.LinkOption.NOFOLLOW_LINKS;

import java.io.File;

import java.io.IOException;

import java.nio.file.FileSystems;

import java.nio.file.FileVisitResult;

import java.nio.file.Files;

import java.nio.file.Path;

import java.nio.file.Paths;

import java.nio.file.SimpleFileVisitor;

import java.nio.file.StandardWatchEventKinds;

import java.nio.file.WatchEvent;

import java.nio.file.WatchEvent.Kind;

import java.nio.file.WatchKey;

import java.nio.file.WatchService;

import java.nio.file.attribute.BasicFileAttributes;

import java.util.HashMap;

import java.util.Map;

/**

 * 文件夹监控

 * 

 * @author Goofy a href="";/a

 * @Date 2015年7月3日 上午9:21:33

 */

public class WatchDir {

    private final WatchService watcher;

    private final MapWatchKey, Path keys;

    private final boolean subDir;

    /**

     * 构造方法

     * 

     * @param file

     *            文件目录，不可以是文件

     * @param subDir

     * @throws Exception

     */

    public WatchDir(File file, boolean subDir, FileActionCallback callback) throws Exception {

        if (!file.isDirectory())

            throw new Exception(file.getAbsolutePath() + "is not a directory!");

        this.watcher = FileSystems.getDefault().newWatchService();

        this.keys = new HashMapWatchKey, Path();

        this.subDir = subDir;

        Path dir = Paths.get(file.getAbsolutePath());

        if (subDir) {

            registerAll(dir);

        } else {

            register(dir);

        }

        processEvents(callback);

    }

    @SuppressWarnings("unchecked")

    static T WatchEventT cast(WatchEvent? event) {

        return (WatchEventT) event;

    }

    /**

     * 观察指定的目录

     * 

     * @param dir

     * @throws IOException

     */

    private void register(Path dir) throws IOException {

        WatchKey key = dir.register(watcher, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_DELETE, StandardWatchEventKinds.ENTRY_MODIFY);

        keys.put(key, dir);

    }

    /**

     * 观察指定的目录，并且包括子目录

     */

    private void registerAll(final Path start) throws IOException {

        Files.walkFileTree(start, new SimpleFileVisitorPath() {

            @Override

            public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) throws IOException {

                register(dir);

                return FileVisitResult.CONTINUE;

            }

        });

    }

    /**

     * 发生文件变化的回调函数

     */

    @SuppressWarnings("rawtypes")

    void processEvents(FileActionCallback callback) {

        for (;;) {

            WatchKey key;

            try {

                key = watcher.take();

            } catch (InterruptedException x) {

                return;

            }

            Path dir = keys.get(key);

            if (dir == null) {

                System.err.println("操作未识别");

                continue;

            }

            for (WatchEvent? event : key.pollEvents()) {

                Kind kind = event.kind();

                // 事件可能丢失或遗弃

                if (kind == StandardWatchEventKinds.OVERFLOW) {

                    continue;

                }

                // 目录内的变化可能是文件或者目录

                WatchEventPath ev = cast(event);

                Path name = ev.context();

                Path child = dir.resolve(name);

                File file = child.toFile();

                if (kind.name().equals(FileAction.DELETE.getValue())) {

                    callback.delete(file);

                } else if (kind.name().equals(FileAction.CREATE.getValue())) {

                    callback.create(file);

                } else if (kind.name().equals(FileAction.MODIFY.getValue())) {

                    callback.modify(file);

                } else {

                    continue;

                }

                // if directory is created, and watching recursively, then

                // register it and its sub-directories

                if (subDir  (kind == StandardWatchEventKinds.ENTRY_CREATE)) {

                    try {

                        if (Files.isDirectory(child, NOFOLLOW_LINKS)) {

                            registerAll(child);

                        }

                    } catch (IOException x) {

                        // ignore to keep sample readbale

                    }

                }

            }

            boolean valid = key.reset();

            if (!valid) {

                // 移除不可访问的目录

                // 因为有可能目录被移除，就会无法访问

                keys.remove(key);

                // 如果待监控的目录都不存在了，就中断执行

                if (keys.isEmpty()) {

                    break;

                }

            }

        }

    }

}

JavaAPI监控的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java监控平台、JavaAPI监控的信息别忘了在本站进行查找喔。